Google Reader refresh is painfully slow about emacs_chrome HOT 5 CLOSED

From what view in Google Reader?

I have to say I'm surprised as I use Google Reader extensively and haven't noticed any significant spikes. The extension does scan for textareas but generally there are none in a Google Reader page.

Are you comfortable using the Chrome Developer Tools and running an unpacked extension?

from emacs_chrome.

The Reader view is "All Items", with the side panel hidden (by 'u').

I wouldn't be surprised if the effect I see results from an interaction of EwE and some other extension(s), I've apparently accumulated an unhealthy amount of them over 2.5 years. Also note that the computer in question is pretty pathetic (a 3-year-old Atom netbook).

I'm not really familiar with the DevTools (only ever used the inspector), but I'm not afraid of them either, so do go on. :)

from emacs_chrome.

OK. Go to Google Reader. Hit Shift-Ctrl-J to enable the devtools. Select "Profiles" and hit the record icon ("Start profiling", circle bottom left). Go back to reader and re-load and do some stuff. After a while go back to the profile window and toggle the record button and you should get a dump of the CPU time used while running Reader.

On my system findTextAreas is responsible for about 1.27% of the total execution time.

from emacs_chrome.

Two things:

• Edit with Emacs now uses mutation summaries to reduce the load caused by a very Dynamic DOM
• Google Reader will soon close down

I shall close this issue assuming there are no objections.

from emacs_chrome.

Two things:

• Edit with Emacs now uses mutation summaries to reduce the load caused by a very Dynamic DOM
• Google Reader will soon close down

I shall close this issue assuming there are no objections.

from emacs_chrome.