Explore the possibility to make use of sampling tool to provide pre-line accurate profiling of javascript applications. More details in: https://bugs.webkit.org/show_bug.cgi?id=20175
Comments from ggaren: > (From update of attachment 22514 [details] [edit]) > There's a lot of overlap between attachment 22487 [details] [edit], which fixes a bug and does > some cleanup, and this patch, which does those things and also adds two new > features: per-line sampling, and sampling built in without a special binary. > > I'd recommend landing attachment 22487 [details] [edit] first. Then, it will be easier discuss > the specifics of a patch that just implements per-line sampling without a > special binary (probably worth a separate bug report). > > Generally, the DoSample opcode code in this patch looks sound. I'm surprised > that the extra branches for callingHostFunction are not costly in the > non-sampling case, but oh well :). > > I don't really think "ENABLE_SAMPLING_TOOL_ALWAYS" captures the difference > between these two modes well. One mode samples each opcode, to show VM > engineers what's hot in the engine; the other mode samples each source line, to > show webpage engineers what's hot in their JavaScript. At least, that's how I > think of it. Do you think of per-line sampling as a feature for VM engineers? > > To be fully viable, I think this second mode -- the per-line mode -- would need > to solve three more problems: > > (1) Dynamically recompile functions that were compiled before sampling started, > so they get sampled, too. (The current user-visible profiler is able to profile > a page without reloading it, so the per-line profiler would need to match that > ability.) > > (2) Remove the existing JavaScript profiler hooks and / or merge with them, to > provide a consistent JavaScriptCore API to the Web Inspector. (This will also > be a ~1% performance win.) > > (3) Web Inspector UI for per-line profiles. Tim Hatcher, Kevin McCullough, and > Adam Roben are the experts on this. > > I'm going to clear the review flag, since I think attachment 22487 [details] [edit] should land > first, and the tasks I've outlined here are pretty beefy, deserving their own > bugs. > taken from: https://bugs.webkit.org/show_bug.cgi?id=20175
May not be a bad idea to do sample based profiling in the web inspector, but I don't think this bug usefully tracks that. Raised this bug to track some comments on a patch that is now a long way out of date (based on the interpreter). Closing, can open a new bug if we get serious about actually doing this.