https://perf.webkit.org/#mode=charts&chartList=%5B%5B%22Chromium%20Linux%22%2C%22SVG%2FSvgHitTesting%3ATime%22%5D%2C%5B%22Chromium%20Mac%22%2C%22SVG%2FSvgHitTesting%3ATime%22%5D%2C%5B%22Chromium%20Win%22%2C%22SVG%2FSvgHitTesting%3ATime%22%5D%2C%5B%22EFL%22%2C%22SVG%2FSvgHitTesting%3ATime%22%5D%2C%5B%22Mac%20Lion%22%2C%22SVG%2FSvgHitTesting%3ATime%22%5D%2C%5B%22Mac%20MountainLion%22%2C%22SVG%2FSvgHitTesting%3ATime%22%5D%2C%5B%22Qt%205.0%22%2C%22SVG%2FSvgHitTesting%3ATime%22%5D%2C%5B%22Qt%205.0%20WebKit%202%22%2C%22SVG%2FSvgHitTesting%3ATime%22%5D%5D&zoom=%5B1362005933164.2751%2C1362074261931.215%5D It seems like we have 1-7% regressions depending on platform.
Looking into it. Will take me a bit to get a good build to profile with. I eyeballed the code and really don't see any explanation for it.
I think this is just because of allocating the Vector of LayerFragments to be way too big. Narrowing it to a size of 1 seems to get the bulk of the time back. Patch coming soon.
Created attachment 190969 [details] Patch
Comment on attachment 190969 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=190969&action=review r=me > Source/WebCore/ChangeLog:7 > + Make sure the allocated vector has a capacity of 1, since that is > + far and away the most common case. You could go higher than 1 if you wanted to, since these are always on the stack anyway.
Comment on attachment 190969 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=190969&action=review > Source/WebCore/rendering/RenderFlowThread.h:43 > +typedef Vector<LayerFragment, 1> LayerFragments; I presume that all the compilers can correctly handle the multiple identical declarations of LayerFragments that will occur when this header and RenderLayer.h are included in the same source file. To be safe, let's let it run through EWS on all platforms first.
Fixed in r144484.
I believe this was the cause of the slowdown. We can re-open if this isn't good enough.