[docs] Remove section about modal performance

[eps1lon]

Testing claim of https://material-ui.com/components/modal/#performance in production bundle. Edit: Results in #17284 (comment)

The section is talking about createElement performance impact in general. It only becomes an issue for very large trees in render functions at which point virtualization/memoization of the component in question is more appropriate.

Closes: #17271

[mui-pr-bot]

No bundle size changes comparing d81e0a7...b320a85

Generated by 🚫 dangerJS against b320a85

[eps1lon]

Between https://5d6d0ecb670755000c993149--material-ui.netlify.com/performance/modal-many-elements/ and https://5d6d0ecb670755000c993149--material-ui.netlify.com/performance/modal-single-element/ we have .5 - .8ms difference on an update.

This is negligible. The section only applies to owners of very large element trees and even then is the createElement call likely not the bottleneck. If it becomes a bottleneck common refactoring practices (large funtions are hard to reason about etc.) apply as well.

[oliviertassinari]

I don't fully remember the context for this section in the documentation. It originates to when I was using Material-UI at Onepixel. I have no objection to removing it, if it's truly useful, the developers will let us know and we can simplify revert.

[eps1lon]

I don't fully remember the context for this section in the documentation. It originates to when I was using Material-UI at Onepixel. I have no objection to removing it, if it's truly useful, the developers will let us know and we can simplify revert.

It's easy to forget some expensive function calls (or many moderately expensive calls) in large JSX trees which might explain a larger impact than just createElement calls. But then again you have more of a problem with a component that's just too big to fully understand and not necessarily a performance problem.

That's also why I prefer to use intermediate variables instead of inlining the function calls. Makes it easier to spot what's actually happening.

+ const className = clsx(a, b, c, [d, e], { f, g });
+ return <div className={className} />;
- return <div className={clsx(a, b, c, [d, e], { f, g })} />;

Size concerns are either negligible or can be optimized by a compiler (I really need to look into closure compiler. React core is using this as well and they are even more liberal with intermediate variables.)

[oliviertassinari]

The limitation with the intermediary className variable is that it allows the definition of the class names and the application of them to be decorrelated, I have seen components where there were a gap of dozens of line of codes.

I think that the code is easier to read when the style is as close as possible to the element. I think that it's part of the reason why the styled-components API is popular.

Lately, I was going crazy having to go back en forth between my large render method a the bottom of the page and my large style sheet declaration at the top. (This problem can be solved with two tabs in the editor)

[mbrookes]

This problem can be solved with two tabs in the editor

Facepalms for not doing that in the past. (scroll up, scroll down, scroll up, scroll down... )

[oliviertassinari]

@mbrookes I have never used this feature yet, I remember looking at it 5 years ago (a C teacher wanted the students to learn and use this feature of vim), and thought, Nah, let's hope I never need that 😆.

[joshwooding]

@oliviertasinnari

Nah, let's hope I never need that 😆.

You just summed up most of my experience with learning vim.