styled-components: getStyleTags method very slow in v5
Hi all,
Upgrading my company’s large codebase to v5 and we’ve seen a performance downgrade. Here are the times I recorded from our server for each styled-components specific methods we use:
| v4 | v5 |
|---|---|
| ServerStyleSheet: 5.355ms | ServerStyleSheet: 0.210ms |
| getStyleTags: 0.916ms | getStyleTags: 10.355ms |
| ServerStyleSheet: 2.883ms | ServerStyleSheet: 0.039ms |
| getStyleTags: 0.789ms | getStyleTags: 9.055ms |
| ServerStyleSheet: 4.064ms | ServerStyleSheet: 0.030ms |
| getStyleTags: 1.472ms | getStyleTags: 5.485ms |
Nice to see ServerStyleSheet constructor is much faster now! But the worse getStyleTags is not worth upgrading to. ~Wondering if it’s related to my Node version.~ Just tried latest stable release Erbium and have the same results.
Environment
## System:
- OS: macOS Mojave 10.14.6
- CPU: (8) x64 Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
- Memory: 1.35 GB / 16.00 GB
- Shell: 5.3 - /bin/zsh
## Binaries:
- Node: 10.15.0 - ~/.nvm/versions/node/v10.15.0/bin/node
- npm: 6.13.4 - ~/.nvm/versions/node/v10.15.0/bin/npm
## npmPackages:
- babel-plugin-styled-components: ^1.10.6 => 1.10.6
- styled-components: ^5.0.0 => 5.0.0
Steps to reproduce
Update styled-components to v5 and jest-styled-components to latest
Expected Behavior
Expect to see a significant reduction in overall render time
Actual Behavior
Experience significant reduction in ServerStyleSheet time but overwhelming increase in getStyleTags
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 2
- Comments: 43 (18 by maintainers)
@tonycassara If you read the code that grows the
groupSizesbuffers as needed, it’s hard to spot a small mistake in the formula that calculates the next size, but it is there.What tipped me off to this mistake was another issue. There the author has a leak and is likely creating new components dynamically. The odd thing was that he got a
RangeErrorfrom the buffer resizing code around 5,888 groups already.Turns out my formula to grow the buffers didn’t make much sense when I took another look at them 😅 So buffers that we’re way too large were being allocated when a certain threshold was crossed.
Hey @kitten @probablyup wanted to say thank you again, I’ve updated to 5.0.1 and we saw a 100ms decrease in time to content loaded and time to interactive on our heavier pages. Incredible!
Wow this is incredible! Could you please help me understand your changes?
It seems you increased the buffer size for the typed array and then increase the size if the total number of tags is greater than that default size? How would that affect performance so much? Because it has to go through potentially another 256 tags before hitting the new size?
Thank you again for finding a solution, really excited to be able to implement this once its released!
They should be equivalent, but the latter just to be more specific!
On Thu, Jan 30, 2020 at 1:57 PM Tony Cassara notifications@github.com wrote:
Can you try out
styled-components@5.0.0-testdeoptand let me know how that goes? It’s based on https://github.com/styled-components/styled-components/pull/2983When profiling, we’re specifically looking for “eager” deopts which have more severe performance penalties
Thank you both! I’ll try these tomorrow morning.
So there’s not really any reason why this would become this much slower other than if you’re creating a lot of
StyledComponents dynamically (inside render / other components) which isn’t supported.I’ve got an explanation of why this is an issue here: https://github.com/styled-components/styled-components/issues/2753#issuecomment-533073888
I’m only suspecting that this may be the case though, since as you’re creating more components, your performance during SSR CSS outputs will degrade linearly.
Also without any code or hints to go on this isn’t really something we can go after or inspect 😕