[docs] expand on sx performance tradeoff
@siriwatknp is already working on this.
Since Aug 15, 2024.
- Dominant language
- JavaScript
- Stars
- 99.1k
- Forks
- 32.5k
- Avg merge
- 2d 17h
- Merged PRs (30d)
- 106
Description
Related page
https://mui.com/system/getting-started/usage/#performance-tradeoffs
Kind of issue
Missing information
Issue description
Helllo! Performance tradeoff page for sx prop lists a comparison between 4 ways of styling your components:
| Benchmark case | Code snippet | Time normalized |
|---|---|---|
| a. 1,000 primitives | <div className="…"> |
100ms |
| b. 1,000 components | <Div> |
112ms |
| c. 1,000 styled components | <StyledDiv> |
181ms |
| d. 1,000 Box | <Box sx={…}> |
296ms |
I simply want to see 2 more cases:
e. <Box p={...} m={..}> (in other words, styled only with Box properties and I would hope that it's exactly the same as case d, but I don't know it.
f. This case, which somebody wondered before me, but nobody answered:
https://stackoverflow.com/questions/71481181/in-mui-v5-sx-prop-is-there-a-performance-difference-between-passing-an-object-li
const sx = {p: 2};
const MyDiv = () => {
return <Box sx={sx}/>
}
So, the same as d, but with sx object lifted up, meaning it's hopefully isn't re-created 1000 times.
It would also be very nice to see what is the difference in terms of memory use. I tried using window.performance.memory and Memory tab on chrome myself (for about 5 minutes) but I failed to isolate this.
Context
I sort of expect an argument in PR's at my place between d and f - d is inline, but f hopefully helps to fight this:
Thanks!
Search keywords: sx prop performance memory tradeoff
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.