| Summary: | Web Inspector: Better handle JavaScriptCore Recompilation for Inspector (Debugging, Profiling) | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Joseph Pecoraro <joepeck> |
| Component: | Web Inspector | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | graouts, inspector-bugzilla-changes, saam, webkit-bug-importer |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | All | ||
| OS: | All | ||
It would be good to avoid attaching the debugger if all breakpoints are disabled. |
* SUMMARY Better handle JavaScriptCore Recompilation for Inspector (Debugging, Profiling). There are two aspects to this bug: 1. Recompilation is work that should not be unnecessarily performed. - Inspector should do a better job of only triggering recompile to avoid unnecessary work 2. Enabling each set of extra byte codes incurs a performance cost of just running JavaScript. - Inspector should do a better job of informing the user / changing the conditions based on the use case - Generic debugging should not need profiling overhead (exception right now is console.profile which may happen at any time) - High Fidelity profiling may not want debugging overhead (debugging incurs about a 2x slowdown) The biggest concern I see right now is the 2x overhead of Debugging, which would skew high fidelity profiling scenarios. The overhead of the sampling profiler may be so low that it would be reasonable to keep it on all the time while the inspector is open. * NOTES - Currently open the inspector causes "2 recompilations" as soon as a frontend is created - 1 for debugger attaching to add "Debugging" byte codes (for breakpoints) - 1 for profiling (TimelineAgent) to add "Profiling" byte codes - I don't know at the moment if a recompilation actually does any immediate work or not. I suspect it doesn't.