imsky / holder

:city_sunrise: Client-side image placeholders.
http://holderjs.com
MIT License
5.84k stars 592 forks source link

high cpu usage #229

Open aparmar opened 4 years ago

aparmar commented 4 years ago

On my machine, there is high cpu usage on pages that use holder. Traced it back to these lines in index:

    // Done to prevent 100% CPU usage via aggressive calling of requestAnimationFrame
    setTimeout(function () {
        global.requestAnimationFrame(visibilityCheck);
    }, 10);

Since this is a recursive call, can we only make these calls on DOM changes? Or pehaps a way for the developer to turn off the timeout, and manually call Holder when a change has occurred.

imsky commented 4 years ago

sure, this is possible to change. i think re-rendering on DOM changes is worth trying, that's been on my list of v3 changes. for v2, i think your suggestion of turning off the timeout makes sense as a quick solution.

could you add some background about your usage of Holder? is it on a page with a lot of placeholders or a lot of dynamic Holder instantiation? i'm interested in understanding why the CPU usage is so high.

aparmar commented 4 years ago

I have templates, enclosed in "script" tags, which get instantiated as the visual elements are needed by the page. Most of the time, the page has less 10 images, which use holder. For the testing below, there is only have 1 holder instance loaded and 0 placeholder images since I'm still on the login screen.

Did some profiling, with results below.

Setup: Chromium 83 on Debian 10. For testing, there is only 1 tab open, which is my application called "System Admin". Holder version is 2.9.6. For consistency, the browser was closed and re-opened for each test.

Here is a picture with holder turned on

image

Here is the same exact setup, with holder turned off

image

Now same page, with holder on, but setTimeout changed to 100ms, instead of 10. I believe this timeout is still fairly fast from a user perspective.

image

Hope this helps.