Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 158 Stack Exchange communities.

What is meta?
Here's how it works:
  1. Any Stack Exchange user can ask a question
  2. The community provides support, votes on ideas, and reports bugs
  3. Your voice helps shape the way Stack Exchange operates

I had left my browser open at the beta review screen (where it says "there are no more items left for you to review") while I was doing something else. However I soon noticed that the PC's fan was struggling, and sure enough checking Task Manager showed that the browser was consuming CPU. Navigating to another page (e.g. Questions) made the problem go away.

I then noticed the same thing happening on the User page for Community. This time I had a bit of luck with my C++ debugger - I was able to find that the page was continually reparsing the same 6MB of JSON. (I said 3MB in a comment but I forgot that JS chars are UTF16). I had tried using a JavaScript profiler but I couldn't get it to give me anything more accurate than the source URL and line number.

Is there some reason why there is code on the page that is continually parsing the same string? I couldn't see anything obviously happening - I wasn't even interacting with the page and it was still consuming CPU.

share|improve this question
Its simple Auto-Refresh feature. Just like you get new question's notification on main page. – Lucifer Oct 18 '12 at 14:32
@Lucifer but I don't see any CPU being consumed on other pages... – Neil Oct 18 '12 at 14:36
This is browser issue. What browser you have? – Shadow Wizard Oct 18 '12 at 14:51
If Chrome, this might be related. – Shadow Wizard Oct 18 '12 at 15:01
My debugger suggests that there's a repeating 1s [why 1s?] timeout at around line 44 of, unfortunately the code there takes my browser 1.1s to execute. – Neil Oct 19 '12 at 10:56
Most of that is taken up by repeatedly parsing the same 3MB of JSON... – Neil Oct 28 '12 at 21:52
Why do you ignore comments? What browser do you have? It's really not hard to answer. – Shadow Wizard Oct 28 '12 at 22:02
+1 to counter children's downvotes – Alf P. Steinbach Oct 29 '12 at 3:30
@ShaWizDowArd Does "Gecko 4 based browser" and "Gecko 18 based browser" suffice? – Neil Oct 31 '12 at 1:14
@AlfP.Steinbach I downvoted because the bug report is incomplete and not helpful. The first step to debugging is almost always to reproduce the problem, and by not providing the browser the OP is making it exceedingly hard to verify this bug report (I just tried it, and can't - 3 megabytes is a lot of data, and I just can't find that data from the files the page loads or in any of the client-side storage spaces) – Yi Jiang Oct 31 '12 at 5:35
@Neil No, it unfortunately does not. Does your browser not have an About box with the version number and name of the software? You can usually find this in Help/About (Apple/About on OSX). If you're rolling your own browser, then it's up to you to debug this behaviour, not MSO. – darvids0n Oct 31 '12 at 6:03
@TimYiJiang If you think Stack Overflow shouldn't be trying to store 3 million characters of data, then I'm willing to log a new question for that part of the problem, and I even have sample data captured, although I don't have anywhere I can easily upload it. – Neil Oct 31 '12 at 12:57
up vote 1 down vote accepted

The History plugin used by the review queue sets up a function to save data to sessionStorage on an interval of History.options.storeInterval milliseconds. This is apparently a workaround for an issue with Internet Explorer where using handlers on beforeunload and unload wasn't always producing the desired results.

According to the source comments, both the normal approach and the workaround are enabled on all browsers for the sake of consistency, even though the latter is only needed for Internet Explorer. This would make the behaviour technically , albeit unnecessary in your case.

I'd have to take a deeper look to see if there's perhaps a cleaner solution to the problem the plugin is trying to solve, but for the meantime I did throw together a small userscript which will allow you to disable the problem code for other (userscript-supporting) browsers*.

*This shouldn't impact the functionality of the page at all, but it goes without saying that if anyone runs into problems with the review queue and is also using this script, they should disable it and confirm any issues persist before reporting them as bugs on Meta.

share|improve this answer
It's been so long since I used Internet Explorer that I didn't even know that it supported session storage! – Neil Oct 31 '12 at 8:35
Yep, as of version 8 it seems. – Tim Stone Oct 31 '12 at 8:43
Thanks, I was able to simplify your user script to the following bookmarklet: javascript:clearInterval(History.intervalList.shift()) – Neil Oct 31 '12 at 12:54
In fact the same fix also seems to apply to the User page too! – Neil Oct 31 '12 at 12:54

JSON.parse was slow because I was using a testing build that not only does extra bounds checking during JSON.parse but also had compiler optimisations disabled. This means that even on my fast PC it can only parse a shade under 11 million characters per second.

By comparison if you remove the bounds checking only it improves to over 18 million cps; if you enable compiler optimisations only then it improves significantly to over 122 million cps while if you do both then you get a top speed of over 162 million cps.

Note that the JSON parse wasn't responsible for all of the CPU usage but it was the single largest contributor.

share|improve this answer
This might really be a bug, but we really need to know what browser you are using to do anything with it. Please provide that info. Your not providing that info may be the reason for your downvotes. – hexafraction Oct 29 '12 at 10:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .