and also brings up the slow script warning quite a lot. (every 10 seconds or more often).
I just loaded up my usual demo, paused at a breakpoint, and all the other panels seemed as responsive as ever to me. Namely, very responsive. Can you provide a publicly available URL that demonstrates the problem. And list specific panels and function you are trying which is slow?
Sadly not, this is in the development version of of the tool I develop. This happened only with the latest nightly builds from I'd say about yesterday on.
So you're saying inspector is only slow in YOUR app, not in any other web site you've run across? We won't be able to help without some clues.
Well, it's not that I'm intentionally searching for bugs in the web inspector, it's just that I'm using it a lot and keep finding issues. So ignore it if you will, but use it as a data-point to know when this started. It definitely felt as if the debugger was slowing its own execution while halting at one place.
Sorry for being terse. I don't want to ignore this, but I don't know where to even begin. Any other leads on where to start, like: - existing public web sites that exhibit the problem - specific things that seem slower If you're up for it, you could try profiling the inspector when you notice this problem. Within the inspector, right-click to bring up the context menu, and select "Inspect Element". That will launch an inspector on the inspector. From there, you can start the profiler. Let us know if you see anything obvious. And since we're still in data collection mode here, would be nice to know OS and OS version; the bug says 10.5; might you be running on 10.6 instead? I was also wondering if you perhaps have any plugins loaded in your app (like Flash). And you should also disable any InputManager "plugins" you have loaded; see: http://pimpmysafari.com/blog/simbl-and-inputmanagers---an-explanation
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
As for plugins, I do have Quicktime, Java, Flash and ClickToFlash installed I know however that neither of these plugins are used on the pages I saw this problem (nor on any of the pages open in the background). They where all pure js,xhtml and css. As for input managers... No SIMBL plugins and no InputManagers.
Are you pegging the CPU? We had a problem at one time with the syntax highlighter causing 100% CPU usage. I wonder if there's something there. If so, how big are the JS files that you're loading?
It could be due to slow garbage collection, since there are lots of javascript objects that can't be collected (from the Inspector and paused page).
No, the system load was normal, it was just the inspector that was very slow. The JS-Files where normal size. jquery minified and then some more (all less than 1000 lines) However the highlighting happened in chungs of about 20 lines, each taking about 4 to 5 seconds. I am not sure anymore, but I think each chunk was accompanied by a slow script warning. Re Garbage collection: Could be - next time this happens I'll try to inspect the inspector.
I bet this was the recent regression in appendChild when a document fragment during syntax highlighting. (GC related.) *** This bug has been marked as a duplicate of bug 31237 ***
I'd like to add though that this only happened during startup - normally layout was very fast (and with the same build too)