JavaScript execution is dramatically slower while Drosera is attached. It's likely that much of this slowness is due to WebKit making a cross-process call to Drosera for every line of JavaScript executed, even if Drosera has no breakpoints set.
<rdar://problem/5792378>
One possible way we could solve this would be for WebKit to be aware of Drosera's breakpoints and only make cross-process calls when a breakpoint is hit or Drosera requests that we step. Another possible way to solve this would be to move debugging to be in-process (as covered by bug 17134).
*** Bug 17554 has been marked as a duplicate of this bug. ***
While a lot of the slowness surely comes from the cross-process calls, some of it definitely comes from WebCore/JSC's debugger infrastructure. Adding a single no-op JavaScriptDebugListener to WebCore's JavaScriptDebugServer caused SunSpider to be 2.42x as slow. Here are the actual results: Without a JavaScriptDebugListener: http://webkit.decenturl.com/sunspider-without-javascriptdebuglis With a JavaScriptDebugListener: http://webkit.decenturl.com/sunspider-with-a-javascriptdebuglist
I just tried this with Firefox 2 and Firebug. The performance was not significantly different when Firebug was disabled vs. enabled. Firebug disabled: http://webkit.decenturl.com/sunspider-without-firebug Firebug enabled: http://webkit.decenturl.com/sunspider-with-firebug
Strangely, changing JavaScriptDebugListener to use const KJS::UString& instead of const String& did not improve performance on SunSpider at all, even though it should reduce the number of strings allocated.
Drosera is going away and JS debugging is now happening in the WebInspector.
Closing since Drosera has been replaced by the new Web Inspector debugger. Moving to the New Bugs component so the Drosera component can be closed and removed.