[Webkit-unassigned] [Bug 31409] Using other inspector panes while stopping at a breakpoint is _very_ slow

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=31409


Martin Häcker <spamfaenger at gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         OS/Version|Mac OS X 10.5               |Mac OS X 10.6




--- Comment #6 from Martin Häcker <spamfaenger at gmx.de>  2009-11-14 02:16:15 PST ---
Ah, I'll add data with pleasure.

* I haven't seen this happen with public websites - but I don't regularly debug
those, so it's hard to tell.
* I did see something similar happen (but I'm not sure it's related) where
halting on a breakpoint in my internal app blocked some other website from
loading when it wanted to execute js (I did assume though that this is because
there is only one js interpreter for all open pages - this doesn't really hold
though, because the debugger is written in js too, so it can't bee that easy)

Specific things that where slower:
* Stepping in the debugger
* Syntax highlighting in the debugger
* Switching between different panes
* Choosing a resource in the resource inspector

I have since noticed that this happens much more often if you open the debugger
directly on startup of webkit. Not a good reproduction, but it seems to happen
more often this way:

* Open Webkit with some js heavy pages
* Open a js unit tests suite in one tab
* Make sure that all these pages come from a not so fast webserver i.e. one
that gives you some seconds delay before it sends over the pages (easier to
reproduce that way)
* Quit WebKit
* Open it again
* Immediately choose, restore all tabs from last session
* Open the debugger in the testsuite and try to stop at a unit test

HTH

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.