3 ms·

Finally my test page[1] no longer crashes my browser with the dev tools open, and appears to run the same speed with and without the dev tools open. I don't kno

by eterm 11y ago

Finally my test page[1] no longer crashes my browser with the dev tools open, and appears to run the same speed with and without the dev tools open. I don't know if it's related to these changes but clearly it could be. [1] http://rcocks.github.io http://rcocks.github.io Edit: Actually it seems to not happen if I don't go to the "inspector" tab but go straight to the performance tab. Ah well, shame there seems to be a lingering issue but I'm happy that I have a workaround now anyway. (It used to crash hard on the performance tab too.)

dblohm7 11y ago
Please report this!
- eterm 11y ago
  Don't worry, it has been previously reported at bug#1123322 [1]. I've updated it to note my latest findings. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1125322 https://bugzilla.mozilla.org/show_bug.cgi?id=1125322
malkia 11y ago
You are also measuring parseFloat(hdn.value) - but I haven't measured how much of impact it is. EDIT - Turns out it takes significant amount of time compared to the rest of the frame, more on chrome, a bit less on Firefox (but the timing profiles are very different on the two browsers). parsing floats is not fast! :) (Many edge cases)
- eterm 11y ago
  Oh I know! I realised that later on when I reviewed the code but I gave up worrying about demonstrating the speed of DOM access* when it started to crash my browser! So I've left this version here for posterity. * I wanted to demo to some people why it's better to write javascript that avoids going back and forth to the DOM all the time.