0

I have a chrome extension that is causing user's laptops to slow to a crawl and realllllly use a lot of CPU (or at least causes their fan to go nuts).

I'm wondering how I can profile this, or see what's going on.

Some theories to help guide:

  1. extension needs (unfortunately) to do some polling. I won't go into why this is the case, but trust me that it does.

What this ends up looking like, however, is:

setTimeout(function() {

    // our inner scrolling loop
    scrollingTimerId = setInterval(function() {

        // did the user change the URL?
        if (!isModalUrl(window.location.href)) { 
            clearInterval(scrollingTimerId);
        }

        // scroll!
        doScroll();

    }, SCROLL_DELAY);

    // our loop to check if we're done
    isDoneTimerId = setInterval(function() {
        ...

    }, OTHER_DELAY);

}, TIMEOUT_DELAY);

Perhaps there is some failture to cancel setInterval or something that's causing the usage to increase over time?

  1. extension also sends messages to ALL tabs on certain events. Could this be an issue with multiple Chrome windows open?

Trying to hunt down what performance issues it could be, and also where to look. Perhaps there is a good tool I don't know about in the Chrome dev tools inspector?

lollercoaster
  • 15,969
  • 35
  • 115
  • 173
  • 1
    Too few details to see what is your problem. BTW: Why do you need wrapping `setTimeout` there? – hindmost Jul 07 '17 at 09:26
  • the page the extension processes is pretty adversarial, and changes what elements are called when loaded into DOM. also most of the elements are loaded via JS so "on page ready" type of stuff doesn't work. outer setTimeout is to wait for general page readiness. it's hacky but works far more often than "clever" methods. would that cause significant performance overhead? – lollercoaster Jul 07 '17 at 09:28
  • Still obscure. You've posted general phrases and some pseudocode and really expect that someone will help you with your problem? – hindmost Jul 07 '17 at 09:34
  • _outer setTimeout is to wait for general page readiness._ What's wrong with `window`'s `load` event? – hindmost Jul 07 '17 at 09:35
  • I'm asking for ways to track down the problem. To help me debug. So yes. To your second question, like I said the page's JS loads oftentimes after the `load` event... – lollercoaster Jul 07 '17 at 09:37
  • _the page's JS loads oftentimes after the load event._ Have you heard about [MutationObserver](https://developer.mozilla.org/en-US/docs/Web/API/MutationObserver)? Also see [this question](https://stackoverflow.com/questions/3219758/detect-changes-in-the-dom) – hindmost Jul 07 '17 at 09:40
  • The direct answer to your question is devtools [Performance timeline](https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/) to debug your content scripts and background page. – wOxxOm Jul 07 '17 at 09:41
  • RE mutation observer, yes I use it. like I said the naming and structure of the page is unreliable and as such, the initial start requires less finesse. – lollercoaster Jul 07 '17 at 09:42
  • As written, your question reads as a mix of debug this for me (without actual code), how do I debug this (which is a bit broad, without more detail), and what are the tools for me to debug this (off-topic resource request)? Please [edit] your question to focus it on one thing, not a shotgun of multiple things. As your question is now, we might be able to make suggestions which would help, but we can't actually *answer*. – Makyen Jul 08 '17 at 04:50
  • 1
    Two things immediately stand out in your pseudo code: A) You are not preventing the start of multiple interval timers doing the same thing (a typical problem, which could cause your issue). B) There's nothing preventing the interval from running forever. While this *might* be OK, it's almost always a good idea to limit the amount of time that your code is willing to sit around waiting for some specific thing to happen. After some point it, usually, is much more likely that you've failed to detect what you were looking for, or the thing is never going to happen, perhaps by user choice. – Makyen Jul 08 '17 at 04:57

0 Answers0