Performance impact on continuous setTimeout?

[ryanmclaughlin]

I'm curious what the impact is of constantly running updateReminders 600 times a minute versus observing changes in the DOM? Any thoughts?

[russelldc]

@ryanmclaughlin
It's a good question, and I don't have the stats right now to answer it accurately. I'd been a little concerned about the same thing, though.

In PR #68, it's been changed to 250ms now (240 times a minute) ... but that's not all that much better. Plus, the longer the timeout, the longer it takes to see visual changes made by the extension. So it would mean more obvious flashes when things change, like applying classes, bundling, reminders, etc.

At some point in the near future, I want to refactor some of the code, especially so that core updateReminders function (which should be renamed because it does a lot more now) would be triggered by observers via Gmail.js. It could track events like:

• load: When the gmail interface has finished loading
• new_email: When a new email appears in the inbox
• refresh: When you click the refresh button
• archive, label, delete, read, unread, star, unstar: Actions taken on an email by the user via the icons or top toolbar

[russelldc]

I did a couple quick tests on the upcoming bundles branch, with Chrome's built-in Task Manager open to the side.

For both tests, I had the tab focused, in my inbox folder, not moving the mouse. I waited for the initial loading and network spike to subside. This is on a Mid-2015 Retina MacBook Pro.
With the extension off, I was hovering between 0.1 - 0.5% CPU usage, besides some spikes now and then.
With the extension on, I was hovering between 1.4 - 2% CPU usage, besides some spikes now and then.

So, not too bad, but hopefully that Gmail.js lib could bring it down even further.

[ryanmclaughlin]

@russelldc Nice work. Good to see it's not terrible but definitely not great.

gmail.js and Inboxsdk have the same problem I believe, their handlers have a hard time observing a change that Gmail makes to the DOM after 10s or so after loading. I've tested both libraries including manually adding an observer to watch for changes to the inbox emails list by adding a class on each email, but Gmail still somehow rerenders the inbox 10s after load and other times as well and removes everything that was changed.

Hope someone can figure this out.

[russelldc]

@ryanmclaughlin Agh, that's disturbing...

If you saw what you think you saw (ie. it wasn't just that you were using it wrong), then it might have something to do with the recent changes to Chrome over the past year or so, when they started throttling unfocused tabs/windows.

Wait, actually, you didn't specifically mention the problem coming up when it was in the background. You're saying you can sit there and watch the page, and 10 seconds later, those libraries' observers stop working?

[ryanmclaughlin]

Yeah, actively watching the dom. It's why there's a setTimeout on updateReminders currently. If you try adding a class when the page loads to an email, any changes are reverted.

For example: try just running document.querySelector(".zA").classList.add("new-class"), that class will be removed after about 10s because the Gmail does something to redraw the inbox. I tried setting a MutationObserver (which is what I believe gmail.js and Inboxsdk use to monitor changes) to catch when this happens and to re-apply the class, but it doesn't catch it 100% of the time. Perhaps I wasn't doing something right. The same goes for when I tried using the handlers provided by the libraries. But, that was just my attempt. Sure someone else can figure it out.

[russelldc]

Just wondering, which events were you observing with Gmail.js?

I still haven't tried it out myself, yet. To solve the issue you're talking about it seems you'd need to look at the following events, with gmail.observe.on(action, callback) and/or gmail.observe.after(action, callback):

• poll - When gmail automatically polls the server to check for new emails every few seconds
• new_email - When a new email appears in the inbox
• refresh - When you click the refresh button
• (maybe?) http_event - When gmail any CRUD operation happens on gmail

[ryanmclaughlin]

I can't remember to be honest. I think it was gmail.observe.after("load_email_data", callback)? I'm sure there's a better way; I think http_event would be interesting.