Material-ui: [Checkbox] Major performance problems

[AndrewMorsillo]

Checkboxes are VERY slow. I have a list of 50 items each each with 2 checkboxes, making a total of 100 checkboxes. This takes almost a second to render on a 4.2ghz i7 in the latest chrome.

The top two entries from Perf.printWasted() when rendering this list

Owner > component                Wasted time (ms)           Instances
"EnhancedSwitch > ClearFix" 320.1149999999725   200
"TaskContainer > Checkbox"  217.61999999996624  86

If I remove the two material ui checkboxes and replace them with normal inputs rendering time drops from over 700ms to around 70ms. The material checkboxes make rendering this list 10x slower!

[oliviertassinari]

@fignuts Thanks for raising this issue.
I'm really questioning the value of our internal <ClearFix />. It sounds like it's here to prevent issues with floating.

I strongly convinced that we should switch :zap: from the float layout to the flexbox layout model.
It has two performance advantages:

• At the react level, that will allow us to get rid of this <ClearFix /> and the <BeforeAfterWrapper />.
  So we will gain many CPU cycles.
• At the browser level, flexbox are 4 times faster (Chrome) to render:
  https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing?hl=en#use-flexbox-over-older-layout-models.

The best part is that it should be straightforward to change. Easy task for great output :grin:.

[joyfulelement]

This can be easily reproduced with the table component (http://www.material-ui.com/#/components/table).

In addition to rendering time for the table with checkboxes, the table selection behaviour (i.e. checking the checkbox behaviour) would take around 4 seconds to complete with 501 rows table. This was on Intel 3GHz 4 core machine with latest Chrome.

Suggest to verify the performance fix along with the table component for the best result.

[aweary]

I see a similar issue with DropDownMenu as well.

| Owner > component | Wasted time (ms) | Instances |
| --- | :-: | --: |
| "DropDownMenu > ClearFix" | 59.62000000000000273 | 50 |
| "DropDownMenu > NavigationArrowDropDown" | 29.830000000000382 | 50 |

I'd say that on most of my pages that ~70% of wasted time is from some MUI component.
@oliviertassinari any updates on this? Are performance improvements on the roadmap at all?

[mbrookes]

@Aweary - yes, but the guys have been focusing on getting the core cleaned up to make way for these sorts of improvements. As always, PRs are welcome.

[alitaheri]

@Aweary We are moving towards more functional programming. Soon we will be able to memoize the styles, that will drastically reduce the number of instantiations.

[hmeerlo]

Experiencing the same problem but at a much larger scale. I have more than 1200 rows in a table with a Checkbox to select them. There is 21 seconds (!) wasted in the Checkbox. The time wasted seems to be exponential to the number of checkboxes.

[stewartcelani]

Also ran into this issue and have had to remove checkboxes for the moment. Was only using 8 on the page at the time but the component containing the checkbox has to rerender every 2.5-5 seconds based on DB updates so was getting a noticeable fps drop every re-render.
Pity because they're so pretty. =D

[mmazzarolo]

Any news regarding this issue?
Having the same problem in a Table with ~80 rows with checkboxes.
You can see an example here

[ziadloo]

Just to share my findings on the subject, I've conducted a test using a table of 100 rows and 10 columns, once with checkboxes and one other time without them. Of course presence of checkboxes made it slower but even without them the performance needed a boost.

In my test, using Chrome's Timeline, selecting a row with presence of the checkboxes resulted in 450ms while without them the same action took 150ms. Of course it's still too much. I'm not sure how to do a more precise measurement as the row selection is an internal operation and there's no place to put Perf.start and Perf.stop!

In any case I'm grateful for the great work, thanks.

[sunewt]

Hey guys - Really interesting insight into the problem in these discussions. We're running into the same problems with checkboxes as the rest. Is it possible to get an update on any work towards improvements in this area?
By the way, keep up the good work. Material-UI is solid bar the few hiccups!

[gmaclennan]

I had a similar problem and I fixed it by making each checkbox 'pure' with recompose:

import makePure from 'recompose/pure'
import Checkbox from 'material-ui/Checkbox'
const FasterCheckbox = makePure(Checkbox)

This wraps Checkbox in a Higher Order Component which adds a shouldComponentUpdate that only updates when props change.

[sunewt]

@gmaclennan Thanks for sharing! Unfortunately it doesn't seem to make a difference when creating a "large" amount of checkbox components (40-50)

[mark-stopka]

I believe, this issue should be closed in favor of #3289.

[Tzelon]

Hey,
Is there any easy solution for this ?

[oliviertassinari]

@Tzelon Depending on your specific issue. But most of the time it's a bottleneck when re-rendering many Checkboxes. It that case, you should prune the rendering tree.

As #4769 was closed, the performance issue with this component should be solved. I'm closing the issue. Thanks guys.

[tietthinh]

I'm using the example provided from the Demo and I produce 143 RadioButton and it seem still slow
Here is the log from Chrome:

[Violation] 'click' handler took 169ms
[Violation] 'click' handler took 187ms
[Violation] 'click' handler took 196ms

So I'm wonder if the CheckBox fixs work for the RadioButton? Thanks

[oliviertassinari]

@tietthinh You can follow the discussion in #10892.

[nhhockeyplayer]

I am using 36 checkboxes and seeing degradation onclick that spans seconds though I do have some processing going on beneath its a bit unusual

using latest material 2 angular 8

[oliviertassinari]

@nhhockeyplayer We only support React.