… and while you are looking at this one @patrick, I’d really appreciate you looking at my issue too as they could well be related, and my client complaints are growing as well…
A quick recap on how to reproduce it:
IN CHROME…
https://app.workshop-angel.com
Click around the user interface for a few minutes.
Sit and watch the memory usage grow.
There is also an AC2 version at
Didn’t notice a big increase in memory, I noticed with the Performance monitor that the JS heap size goes from 50MB to 100MB and then back again. After inspecting this behavior I found that the only thing running is the scheduler, it takes a while for the Garbage Collection to clean up memory again. Also noticed that the CPU is relative high while being idle on the page, this again is due to the scheduler.
Yellow is the CPU usage and blue is the Memory usage.
The above was when checking the AC1 version of the app.
You can enable the Performance monitor in devtools to see real-time CPU/Memory usage of your page.
Hi @patrick… was this working on my app Workshop Angel, or @sid 's app?
Assuming you were looking at my app… I have 6 schedulers set up, and I actually only use one of them.
This is the one I use:
<dmx-scheduler id="login_timeout" dmx-on:tick="m_login_timeout.show()" delay="28000" noload="true"></dmx-scheduler>
Would things be more memory efficient if I set it to be 466 minutes or 8 hours rather than 28000 seconds?
I also then trigger that scheduler each time the mouse is moved like this…
<body id="index" is="dmx-app" dmx-on:mousemove="login_timeout.start()"
Is this a potentially memory hungry thing to do?
Does the scheduler use a particular part of Javascript which I can do some background reading on?
I then have these schedulers that I don’t currently use which I can delete.
<dmx-scheduler id="autosave_contact_XXX" dmx-on:tick="f_contact.submit();view_edit.setValue('view');hide_labels.setValue(1);flow_unlock_contact.run({})" norepeat="" noload="" delay="10" unit="hours"></dmx-scheduler>
<dmx-scheduler id="autosave_activity_basics_XXX" dmx-on:tick="f_update_activity.submit();view_edit.setValue('view');hide_labels.setValue(1);flow_unlock_activity.run({})" norepeat="" noload="" delay="10" unit="hours"></dmx-scheduler>
<dmx-scheduler id="autosave_price_XXX" dmx-on:tick="f_update_price.submit();view_edit.setValue('view');hide_labels.setValue(1);flow_unlock_price.run({})" delay="10" norepeat="" noload="" unit="hours"></dmx-scheduler>
<dmx-scheduler id="autosave_question_XXX" dmx-on:tick="f_update_question.submit();view_edit.setValue('view');hide_labels.setValue(1);flow_unlock_question.run({})" delay="10" norepeat="" noload="" unit="hours"></dmx-scheduler>
<dmx-scheduler id="autosave_message_template_XXX" dmx-on:tick="f_update_message_template.submit();view_edit.setValue('view');hide_labels.setValue(1);flow_unlock_message_template.run({})" delay="10" norepeat="" noload="" unit="hours">
</dmx-scheduler>
This was testing on your app Workshop Angel, I don’t have access to sid’s app.
mousemove is an event that triggers continuously when moving the mouse, you probably want to use a debounce there.
I noticed that you have an old scheduler version on that page, your version is 1.0.0 while latest stable is version 1.1.0. The latest version has an property noprogress which prevents it from updating each frame and should decrease the CPU usage and probably also some Memory.
yes
Thank you soooo much @patrick, that seems to be the issue. 
Clearly something changed in Chrome recently that made the scheduler run amok, but now I have it back under control!
Why not reset the scheduler on click instead. That’s what I do and I have no issues at all.
<body is="dmx-app" id="dashboard4" dmx-on:click="schedulerLogout.start()">
Yes, I was thinking that too @brad… it turned out the way I was doing it I had just randomly put there and found it worked okay so not changed it until Chrome decided it didn’t like it any more!
This should all be fixed now in Wappler 6.3.1 with the latest updates on the beta extensions channel.