It's difficult to understand the performance of a large web app nowadays - think GMail scale and beyond, in part because a lot of things happen in the UI thread outside of javascript. For example layout, selector matching and painting can all happen in a deferred way, take a lot of time and yet not show up in any javascript-based profiling or metrics. Even within javascript it's not always obvious why things happen when they do - for example a setTimeout() might get blocked behind an XHR readystatechange handler or a layout causing the timer code to run much later than expected.
To help with this I propose adding a number of instrumentation points within WebCore designed to bracket the more significant pieces of logic that can block the UI thread. Then a client could register itself for the instrumentation points and aggregate statistics or build reports of what's going on while a web app is running. This would not be another generic profiler per se but more targeted at things useful to a web developer. As a nice side effect the instrumentation can have a significantly smaller observer effect than full-scale profiler. I have a basic implementation of the framework and plumbing for WebKit/mac at https://bugs.webkit.org/show_bug.cgi?id=25503 with a simple aggregator for the DumpRenderTree tool. The output looks something like this: $ ./WebKitTools/Scripts/run-webkit-tests fast/dynamic/ --dump Running tests from /usr/local/home/jamesr/WebKit/LayoutTests Testing 57 test cases. fast/dynamic ......................................................... 1.92s total testing time html_write time = 38.554668ms count = 230 recalc_style time = 3.255128ms count = 248 paint time = 58.205367ms count = 70 layout time = 117.240668ms count = 240 all 57 test cases succeeded Any thoughts or feedback? Thanks, - James
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev