Why does it take so much cpu & ram to suspend this webpage?

[Pascal666]

Attempts to suspend tabs showing http://www.illinoiscourts.gov/SupremeCourt/Rules/Art_III/ArtIII.htm result in the tab maxing out a cpu core, using ever increasing amounts of ram, and Page Unresponsive warnings (if the tab is not minimized), before it is finally suspended several minutes later.

I'm wondering if this problem happens with all webpages, it is just easier to see with this one. If found & fixed maybe all tabs would suspend a whole lot faster.

[deanoemcke]

My first guess would be that you have the 'Screen capture' setting enabled. The link you sent is has a very large amount of content. It is most likely trying to convert that into a very large image.
The issue raised is valid however. The extension needs to be able to handle situtations like this in a performant way.

[Pascal666]

Yes, the Screen capture setting is enabled. The displayed images do not have a scrollbar so it did not occur to me they may continue off the bottom of the screen, but sure enough, if I zoom out on the text header it pulls more image onto the screen. However, if I right click on the image and select "Open image in new tab" I can see that the image is only the size of the screen, including the area normally used by the text header. If it is converting the entire page to an image, it appears to be discarding most of it.

[deanoemcke]

The latest version of the extension (v6.30 - available from github only, not on the webstore) has a slightly different approach to screen capturing. It allows to either capture 'visible screen' or 'the entire page'. This allows you to scroll the entire image (if the latter option is selected).
However, both these options appear to have about the same performance in terms of image generation time, so it may not help you with your initial problem. Unfortunately I'm using an external library to do the image generation so it's performance is out of my control.
The page you linked suspends for me in about 7 seconds. Perhaps you're using a much less powerful computer than me? What version of the extension are you using?

[Pascal666]

v6.21 on an Intel Core i7 M 640 (2.8Ghz). Definitely not top of the line, but I wouldn't call it slow. I find that the compare feature at http://cpuboss.com/cpu/Intel-Core-i7-640M works really well, if you want to see how they compare.
I just monitored it closely and that tab went from using about 80MB of ram to 1.8GB and took about 8 minutes to suspend.

[deanoemcke]

Wow. That's crazy. Unfortunately I'm having trouble recreating your issue. Can you give me more information about your system? What OS and version? What version of chrome? How much ram does your computer have? Is there anything else on your computer which might be impacting performance? How many chrome tabs and windows do you have open?

[Pascal666]

Fully patched Windows 7, Chrome 58.0.3029.110 (64-bit), 8GB RAM. I do not have "Use high quality screen captures" turned on. Before the above test, I made sure the cpu was idle and I had over 2.5GB of free RAM so it would not need to swap to the SSD. Suspending that tab only pegs one of the cores, so whatever it is doing looks like it is single threaded. I had 74 Chrome windows and 438 tabs open, but I did a suspend all tabs first so there were only maybe 5 actually not suspended (view-source tabs won't suspend).

If I disable all extensions other than The Great Suspender, reboot, open just that one tab, and then suspend it, it grows from 30MB to 400MB (as indicated by Chrome's Task Manager) and takes 4:15. I enabled a few other extensions and had no change until I enabled uBlock Origin, which made it go over 1.5GB and take 4:30. When I tested with subsets of other extensions (without uBlock Origin) it went over 2GB and 5 minutes. So some extensions seem to make the problem even worse while others have no effect.

I was unable to recreate the problem on other Windows or Linux machines, including an older laptop. The worst I saw on other machines was about 20 seconds, even with the same Windows, Chrome and TGS versions and identical TGS and Chrome settings (synched via Google).

I am at a loss as to why it is just my primary laptop experiencing the problem. I do not have a second Dell Latitude E6510 to test with.

TGS v6.30 appears to have the same performance as above; visable only or full screen makes no difference.

[Pascal666]

I finally figured out how to reproduce this problem on other Windows and Linux boxes. Change the zoom level. At 100% zoom, the page takes 15 to 20 seconds to suspend. At 90% or 110% (only values I tested, but probably anything other than 100%) it takes over 4 minutes on every box I tested.
ctrl-+ zooms in
ctrl-- zooms out
ctrl-0 sets zoom to 100%
ctrl with the mouse scroll wheel zooms in or out depending upon direction
The Chrome menu also has +/- for zooming in/out.

Although it takes longer when you change the zoom level, really 15-20 seconds is even a lot longer than it should take. Instead of trying to figure out why the current screenshot code doesn't like different zoom levels, it may be a better use of time to replace the screenshot code altogether. There are a number of Chrome extensions that take screenshots. Perhaps one of them has a compatible open source license the code could be copied from.

[liamjohnston]

@Pascal666 Wow, good detective work! It is an 'experimental' feature and one that hasn't been touched for a while afaik. It may be that html2Canvas is no longer the best way to do this. Changing this would be a matter of weighing up speed improvements with memory usage (which is the whole point of TGS, and why it's a disabled option by default). Do you know if anyone else has been experiencing this slowness? This is the only report of this issue that I'm aware of, do you have other extensions that could be causing this?

[deanoemcke]

Thanks a lot for working this out @Pascal666
AFAIK most tab screenshot extensions use the native screen capture API provided by google. However, this API will only allow you to capture a 'visible' tab. I need to be able to capture tabs that are about to be suspended which are almost never visible.
The Html2Canvas library I use is the only library I've found that achieves this: https://github.com/niklasvh/html2canvas
Perhaps someone has already reported this issue to him. Actually, I am not using the latest version of the library either. I briefly tested the newer version and it seemed to be significantly slower so I decided to stick with the existing version. Perhaps this newer version solves your zooming issue. I'll try to do some further tests soon.

[Pascal666]

I've now tested a number of webpages of different sizes from different sites. Once you know what you are looking for, it is obvious when suspending any webpage beyond just a couple pages that they take longer with other than default zoom.

The current image capture library appears to be completely useless with some websites, such as https://www.theverge.com/2017/6/2/15722112 . The entire top page on many of their stories is an image from a CDN which does not show up at all in the capture. I don't know if this cross-site issue would exist with any javascript solution though.

@liamjohnston Thank you. I'm sure other people use zoom and thus are running into this bug, but I'd imagine in most cases pages are suspended in the background and are small enough people would never notice. For most pages it will only make a real difference in aggregate, and it will really affect people who have their default page zoom set to something other than 100%. I tested with all other extensions disabled and still saw the problem, just not as severe (400 MB and 4 minutes instead of 2GB and 8 minutes).

@deanoemcke That makes sense. Perhaps this list of a few libraries that appear to implement similar functionality will help:
https://github.com/tsayen/dom-to-image
https://pbakaus.github.io/domvas/
https://cburgmer.github.io/rasterizeHTML.js/
https://github.com/ariya/phantomjs

Thank you.

[deanoemcke]

@Pascal666 I have been through the 4 alternatives to html2canvas you posted. Unfortunately none of them are as reliable as the current solution. dom-to-image seemed the most promising, and indeed manages to capture zoomed pages without problem. but it has other issues - like it fails to capture youtube properly where html2canvas succeeds.

As a work-around for the original issue (excessive CPU usage on zoomed tabs), i have added a new preference 'Enable screen capture on zoomed tabs' which is disabled by default. This is primarily to prevent large CPU usage for those users who are unaware of the issue. As a result they will not get screen captures on tabs that are not at default zoom. This is, i believe, in preference to their CPU maxing out at 100% for minutes on end just to suspend a tab.

Keen to hear your feedback.

[jvschiavo]

What about the latest version of Html2Canvas? How is its performance?

[deanoemcke]

I have had issues with the latest version of Html2Canvas. See the comments in this PR for more info: #562

The new release uses a patched version of an older version of Html2Canvas. This seemed to be the best compromise between performance and compatibility.

[deanoemcke]

It turns out the patched version was super slow. It looks like the most recent alpha is actually really good though so i'm going with that now.

[deanoemcke]

Also, I checked the screen capturing on zoomed tabs with the new version of html2canvas and it seems to have no issues anymore. So I have removed all special handling around zoomed tabs and treat the just the same as ordinary tabs.

[Pascal666]

Thank you. Is it possible for you to release a signed version on GitHub that we can manually install without losing all our settings and saved sessions?

[deanoemcke]

Unfortunately, the chrome webstore manages my private key and i cannot access it :(