Set and clear bookmarks very slow in v13

[Tim Meadowcroft]

Since moving to v13 of Chrome to get the latest dev tools (esp. things like prettify json) I've noticed that setting or clearing a breakpoint has got a noticeable lag - it takes about 2 seconds after I click before the marker shows or clear and for the entry in the Breakpoints list appears or gets removed.

Does anyone else see this - is there anything I can do to make it run all snappy again (other operations seem to work at normal speed still) ?

I'm using Chromium 13.0.782.1 on 32 bit Linux, it also seemed this way in 13.0.772.0

Cheers

--

Tim

[Yury Semikhatsky]

Hello Tim,

I filed a bug on this issue(crbug.com/85029). However, I wasn't able to reproduce it with the following configuration:

Google Chrome	13.0.782.10 (Official Build 87958) dev
OS	Linux
WebKit	535.1 (branches/chromium/782@88129)
JavaScript	V8 3.3.10.6
Flash	10.3 r181
User Agent	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.10 Safari/535.1

I tried setting/removing breakpoints on Google Closure Hovercard example(http://closure-library.googlecode.com/svn/trunk/closure/goog/demos/hovercard.html, file hovercard.js)

and they appear/disappear almost immediately after click. Can you try to reproduce the

issue with that example and latest dev-channel build?

Yury

[Tim Meadowcroft]

Hi Yury,

On Monday, June 6, 2011 9:21:59 AM UTC+1, Yury Semikhatsky wrote:

Hello Tim,

I filed a bug on this issue(crbug.com/85029). However, I wasn't able to reproduce it with the following configuration:

Thanks for that (can't believe I wrote bookmarks rather than breakpoints in the posting title, quite some freudian slip there..)

 

I tried setting/removing breakpoints on Google Closure Hovercard example(http://closure-library.googlecode.com/svn/trunk/closure/goog/demos/hovercard.html, file hovercard.js)

and they appear/disappear almost immediately after click. Can you try to reproduce the

issue with that example and latest dev-channel build?

Still happens on that page. My "about:" details are below.

Chromium	13.0.782.1 (Developer Build 0)
OS	Linux
WebKit	535.1 (unknown@0)
JavaScript	V8 3.4.0.1
Flash	10.3 r181
User Agent	Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.1 Safari/535.1
Command Line	chromium-browser --extra-plugin-dir=/usr/lib/nsbrowser/plugins --no-startup-window --flag-switches-begin --new-tab-page-4 --flag-switches-end
Executable Path	No such file or directory

I disabled all extensions, and that made no difference, but then killed the Flash and GoogleTalk and GPU Process plugins (the latter restarted of course) and closed all other tabs and the delay seemed to vanish.

Restarting the plugins but not extensions feels like it re-introduces part of the delay (maybe a 1 second delay) - my prejudices are pointing at Flash, but I'll do some experimentation and see if I can pin it down more precisely. 

I'll see if I can build the latest dev-channel build but I'm running Gentoo and use the ebuilds to pick up latest versions with appropriate dependencies etc (

 http://gentoo-portage.com/www-client/chromium) so I hope you don't mind if I pursue checking behaviour with various plugins instead. The GoogleTalk plugin is version 1.8.0.0, again installed via gentoo ebuilds.

Cheers

--

Tim

[Yury Semikhatsky]

Thanks for investigating this! Another thing that we suspect is a bug which caused breakpoints duplication when they were saved into local store. Could you open DevTools for the DevTools window (e.g. using Inspect element context menu item on the DevTools window) and type the following in the console of the second DevTools window: 

localStorage.breakpoints

to see whether it contains one entry per active breakpoint?

Yury

[Tim Meadowcroft]

Probably unrelated, but you know the fancy little animation in the dev tools when you press escape to open and close the console part of script view (as the console slides open the buttons slide over and others fade into or out of view)? 

Well if I press Shift-ESC rather than plain ESC, this animation runs smoothly but slowly - taking about 2 seconds to complete (that's how I noticed what it does).

Oh, and the machine has got 8Gb of RAM and a dual core 2.6GHz AMD X2 and very little else running (emacs, a shell console, KDE), so I think it's unlikely that it's simply paging causing the original delay, but I'll also experiment with opening lots of javascript tabs at once etc.

Just saw your follow up about breakpoints in localStorage and that does ring bells.... let me have a look at that.

[Tim Meadowcroft]

On Monday, June 6, 2011 12:23:50 PM UTC+1, Yury Semikhatsky wrote:

Thanks for investigating this! Another thing that we suspect is a bug which caused breakpoints duplication when they were saved into local store. Could you open DevTools for the DevTools window (e.g. using Inspect element context menu item on the DevTools window) and type the following in the console of the second DevTools window: 

localStorage.breakpoints

to see whether it contains one entry per active breakpoint?

Ladies and Gentlemen - I believe we have a winner !!

So, I always thought my breakpoints behaved a little strange, sometimes they'd mysteriously return etc

Doing the above causes the devtools of the devtools console to hang...but killing it and opening another, and then examining localStorage.breakpoints.length reports 2,560,663 items in the array !

I'm guessing this is ... sub-optimal...

Any suggestions how to clean all these out ? Just set the array to empty, or use the Resources tab to examine and clear localstorage for devtools ?

And anything you'd like me to check / dump / summarise before I do so ??

Cheers

--

Tim

[Yury Semikhatsky]

On Mon, Jun 6, 2011 at 3:39 PM, Tim Meadowcroft <mee...@gmail.com> wrote:

On Monday, June 6, 2011 12:23:50 PM UTC+1, Yury Semikhatsky wrote:

Thanks for investigating this! Another thing that we suspect is a bug which caused breakpoints duplication when they were saved into local store. Could you open DevTools for the DevTools window (e.g. using Inspect element context menu item on the DevTools window) and type the following in the console of the second DevTools window: 

localStorage.breakpoints

to see whether it contains one entry per active breakpoint?

Ladies and Gentlemen - I believe we have a winner !!

So, I always thought my breakpoints behaved a little strange, sometimes they'd mysteriously return etc

Doing the above causes the devtools of the devtools console to hang...but killing it and opening another, and then examining localStorage.breakpoints.length reports 2,560,663 items in the array !

I'm guessing this is ... sub-optimal...

Yeah, and it almost exceeds the localstorage quota.

 

Any suggestions how to clean all these out ? Just set the array to empty, or use the Resources tab to examine and clear localstorage for devtools ?

I think the easiest way is to assign localStorage.breakpoints to an empty string but deleting it using Resources panel should work equally well.

 

And anything you'd like me to check / dump / summarise before I do so ??

Other settings shouldn't suffer(if you clear only localStorage.breakpoints), you will only lose all you breakpoints after reopening DevTools. I'd appreciate if before clearing the storage you would evaluate 

copy(localStorage.breakpoints)

in the second console to copy the settings string into the clipboard and then send it to us, this would help us to better understand how to normalize such strings automatically for other users.

Yury

 

Cheers

--

Tim

[Tim Meadowcroft]

Sure thing - I'll email you the file.

I looked at the other properties of the localStorage object and notice that there are also properties such as "nativeBreakpoints:html://<<some-url>>" - these are mostly much smaller but the locahost:8080 one (I'm doing a lot of Google AppEngine development) is about 10k and again contains duplicates.

I guess I should clear these too, and I'll put them in the same dump file I send you (is there a particular reason why the console doesn't let you select and copy output messages any more?).

Thanks for your help, I'll try to keep an eye on this figure from time to time and see if it grows again.

--

Tim

[Yury Semikhatsky]

On Mon, Jun 6, 2011 at 4:35 PM, Tim Meadowcroft <mee...@gmail.com> wrote:

Sure thing - I'll email you the file.

I looked at the other properties of the localStorage object and notice that there are also properties such as "nativeBreakpoints:html://<<some-url>>" - these are mostly much smaller but the locahost:8080 one (I'm doing a lot of Google AppEngine development) is about 10k and again contains duplicates.

Other breakpoints(DOM, XHR,..) are also likely to be affected by this bug so you need to clean them as well if you use those kinds of breakpoints.

 

I guess I should clear these too, and I'll put them in the same dump file I send you (is there a particular reason why the console doesn't let you select and copy output messages any more?).

It should be possible to copy the messages in console. I just thought that copying 2.5mln characters directly to the clipboard would be much faster.

 

Thanks for your help, I'll try to keep an eye on this figure from time to time and see if it grows again.

Thank you for providing detailed feedback on the issue, it's really helpful!

 

--

Tim

[Yury Semikhatsky]

On Mon, Jun 6, 2011 at 3:32 PM, Tim Meadowcroft <mee...@gmail.com> wrote:

Probably unrelated, but you know the fancy little animation in the dev tools when you press escape to open and close the console part of script view (as the console slides open the buttons slide over and others fade into or out of view)? 

Well if I press Shift-ESC rather than plain ESC, this animation runs smoothly but slowly - taking about 2 seconds to complete (that's how I noticed what it does).

This behavior is intentional, when shift is held it's 2000ms compared to 250ms without shift. I don't remember the reason for this though.

Yury

[Tim Meadowcroft]

Other breakpoints(DOM, XHR,..) are also likely to be affected by this bug so you need to clean them as well if you use those kinds of breakpoints.

I cleared them all and restarted the browser and it's all running much snappier now.

I added a note to crbug.com/85029 to this effect - don't know if you want to mark it as related to the bug you mentioned about how the list gets so large.

 

I guess I should clear these too, and I'll put them in the same dump file I send you (is there a particular reason why the console doesn't let you select and copy output messages any more?).

It should be possible to copy the messages in console. I just thought that copying 2.5mln characters directly to the clipboard would be much faster.

Not so much for that entry, but in general .. no ... in my console window I can select text at the prompt, but all the other text (previous commands, output log messages etc) is unselectable (ie enything within div id='console-messages' except for div id='console-prompt') - maybe one attempt in 20 will start a selection using the mouse.

I can expand and collapse objects dumped in the structured view, but I can't select any of the text except if I double click on an item in the structured dump I can edit the value (and as that gives me an edit box I can select and copy text for the value).

And now I find that if I double click on a word in a console log message (ie not the console.dir() dump) then it selects that, and then it seems I can use shift click to extend the selection.

I see various selection event handlers in DevTools.js but it's a bit large for me to debug from scratch :)

If I spot any more pattern to it, I'll post a fresh topic.

Cheers

--

Tim

[PhistucK]

Probably because it is cool.

I, personally, really like it.

:)

(Though sometimes it is annoying, because you actually want the Chrome task manager, hehe)

☆PhistucK

[pra...@gmail.com]

Stil experiencing the lag with 25.0.1364.172 m. Another "victim":

On Thursday, June 7, 2012 1:18:17 PM UTC+2, Martin wrote:

Hello, 

the following applies to both Chrome 19.0.1084.52 m using the 
Developer Tools and Node.js 0.7.6 pre using node-inspector as Debug 
Frontend. 
I've noticed that setting a breakpoint (in frequently executed code), 
no matter if the breakpoint is conditional or not slows down the 
execution of javascript significally. 
The function i'm trying to debug takes around 2 seconds to execute 
without breakpoints. 
If i set a breakpoint i stopped waiting for the end of execution (or 
actually hitting the breakpoint) after 10 minutes! 
Is this a known issue? 
I haven't found anything related in the issue tracker. 

kind regards 
Martin

   --- Ferda