Open aparmar opened 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.
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
Here is the same exact setup, with holder turned off
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.
Hope this helps.
On my machine, there is high cpu usage on pages that use holder. Traced it back to these lines in index:
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.