Bug: Excessive cpu usage of the page when react-devtools is active

[myshov]

When option "Highlight updates when components render" is activated the whole page repaints in rapid succession after the components state has been changed. It causes 100% CPU usage by the browser and unpleasant DX due low fps.

React version: 16.12.0
DevTools version 4.4.0-f749045a5

The sequance of actions is important:

1. Open react application
2. Open react-devtools
3. Check option "Highlight updates when components render" in react-devtools settings
4. Change the internal state of a component
5. In activity monitor there will be 100% cpu usage of the page, or check option "Paint flashing" in rendering pane of chrome devtools

The code example (to trigger the issue: 1) check the option "Highlight updates when components render" and 2) click on the button:

import React, {useState} from 'react';

function App() {
  const [count, setCount] = useState(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      click #{count}
    </button>
  );
}

export default App;

The current behavior

Excessive cpu usage of the page

The expected behavior

Normal cpu usage of the page

[ideffix]

I can take a look on this :)

[ideffix]

@myshov Have you tried it on another machine? It works fine in my Chrome

[myshov]

@ideffix I don't have another machine. But I posted that issue in local chat and at least one more person confirmed the issue

[M-Izadmehr]

@myshov I tried to replicate this issue, however it worked perfectly fine in both chrome/firefox devtools, on Mac laptop.

[myshov]

@M-Izadmehr Hmm... it is really strange. I have checked once again with fresh cra project in Chrome 80 and the problem is still there

[mkrl]

I can confirm it's reproducible, running Chrome 80.0.3987.87, React Dev Tools 4.4.0 & React 16.12.0 on Debian Linux, bundled with Parcel. Also happened to my coworker while building our Storybook with Webpack on Mac.

Here's a bare reproduce minimum that consistently worked across several machines.
https://github.com/mkrl/react-devtools-17935

[M-Izadmehr]

@mkrl Interesting, I cloned your repository it worked fine for me too, it might be a chrome bug on ubuntu, can you also check it with firefox devtools (it is basically the same code base just built for firefox), if it exists there too it means that it is probably related to react-devtools.

[mkrl]

@M-Izadmehr just checked, I was able to achieve a similar behavior in Firefox 72.0. Firefox paint flashing doesn't indicate the entire page being updated in a way Chrome dev tools did, however the CPU usage did skyrocket to 100%.

[naima-shk]

can i take this issue?

[myshov]

@naima-shk hi! As far as I know no one works on this issue so you can take it

[rottencandy]

I tested this on Firefox:68.5.0esr and React Dev Tools:4.4.0-f749045a5 and can reproduce this issue.

But I tested this again after building react-devtools-extensions from master(Dev Tools: 4.4.0-8e6a08e) and this issue doesn't seem to occur.

@myshov can you to test this by building the extension?

[Faelivrinx]

I did some research and results are as follow

CPU: AMD Ryzen 5 3600 6-Core Processor (12 CPU’s)
React Version: 16.20.0

---

1. Firefox: 74.0 x64 & React Dev Tools: 4.4.0-f749045a5 (https://addons.mozilla.org/)

---

2. Firefox: 74.0 x64 & React Dev Tools: 4.4.0-da834083c (sources : tags/v16.13.1)

---

3. Firefox: 74.0 x64 & React Dev Tools: 4.6.0-31734540d (sources : master)

---

4. Chrome: 80.0.3987.149 x64 & React Dev Tools: 4.4.0-da834083c (source : tags/v16.13.1)

---

My pattern to reproduce issue looks like this:

1. Open App
2. Open React Dev Tools
3. Check option "Highlight updates when components render"
4. Update state (only single click)

Tests using the Firefox browser reveal a clear increase in CPU utilization after the component status changes. Chrome browser didn’t manifest this behavior what is confirm attached "CPU History".
I’ve used simple React App created by @mkrl few comments above.
Is anyone working on that issue? If not, I willingly try to resolve it.

[gaearon]

Happy to take PRs! We're not actively looking into this ourselves right now.

[Faelivrinx]

File: react-devtools-shared/src/backend/views/TraceUpdates

It's looks like the problem is in prepareToDraw method. Last line of code: redrawTimeoutID = setTimeout(prepareToDraw, earliestExpiration - now) will starting the redrawing process with a high refresh rate and then cpu consumption increasy dramatically.
Following some stackoverflow topic I've noticed that the max allowed value of setTimeout is 2147483647 (32-bit int) so in most of our cases (if I'm not mistaken) it's redrawing as fast as possible.

Google chrome handles this quite well, I see problems on firefox under ubuntu (I didn't have the opportunity to check on windows for now).
@gaearon could you explain what's the point of refreshing so often? It could be replaced by some const value (e.g 50 ms which will allow redraw canvas 20 times per second)?

[gaearon]

Oh wow. So essentially setTimeout with MAX_VALUE kind of just overflows?

could you explain what's the point of refreshing so often? It could be replaced by some const value (e.g 50 ms which will allow redraw canvas 20 times per second)?

I think it's just a buggy condition. The idea is that earliest expiration would get overwritten here.

I think what the code should do is not call setTimeout when it is still Number.MAX_VALUE because it means we don't have anything to draw. Or refactor this differently somehow.

[Faelivrinx]

Oh wow. So essentially setTimeout with MAX_VALUE kind of just overflows?

Browsers including Internet Explorer, Chrome, Safari, and Firefox store the delay as a 32-bit signed integer internally. This causes an integer overflow when using delays larger than 2,147,483,647 ms (about 24.8 days), resulting in the timeout being executed immediately. source

I think what the code should do is not call setTimeout when it is still Number.MAX_VALUE because it means we don't have anything to draw. Or refactor this differently somehow.

Oh, I see. I'll try to refactor it a little bit but without engaging to refactor other functions. Maybe just reversed conditions will be more readable in this situation.