Optimization of hot paths

[benbryant0]

I was looking into using object literals instead of template literals for CSS with SC and wanted to compare performance beforehand and found a few easy wins. I used stitches-bench since the benchmark package in the styled-components repo hasn't been functional for a while.

I ran most of the stitches-bench benchmarks, comparing the latest main of styled-components with the changes here. Most tests were run for both object and template literals. All numbers given are the average time of a run. These were all based on this commit, just before the recent optimizations that were pushed to main.

The gzip'd size of styled-components.min.js goes up by 32 bytes with these changes.

Benchies

stitches-bench results (Chrome 111)

Create & mount button: 1000 iterations, 20 runs

Version	Time	Improvement
v6	0.178360
new	0.173725	~2.6%

Mount deep tree: 250 iterations, 20 runs

Version	Type	Time	Improvement
v6	object	7.400660
new	object	6.725380	~10%
v6	template	5.396240
new	template	4.987980	~8.1%

Change a variant: 1,000 iterations, 20 runs

Version	Type	Time	Improvement
v6	object	0.061315
new	object	0.053685	~14%
v6	template	0.039755
new	template	0.037960	~4.7%

Change CSS prop: 20,000 iterations, 20 runs

Version	Type	Time	Improvement
v6	object	0.152887
new	object	0.141753	~7.8%
v6	template	0.128297
new	template	0.123021	~4.2%

Sierpinski triangle: 100 iterations, 20 runs

Version	Type	Time	Improvement
v6	object	9.453550
new	object	8.788950	~7.5%
v6	template	8.705250
new	template	8.369000	~4%

Mount wide tree: 50 iterations, 10 runs

Version	Type	Time	Improvement
v6	object	11.584400
new	object	10.300800	~12%

I only ran one of the benchmarks in Firefox, just to sanity check:

stitches-bench results (Firefox 111)

Mount deep tree: 250 iterations, 20 runs (Firefox 111)

Version	Type	Time	Improvement
v6	object	11.342000
new	object	9.752200	~16%
v6	template	9.710400
new	template	8.477800	~14%

The changes

The two main themes here are "regex is slow" and "[...].join() is slow". There are other cases of these that could be improved, but they didn't show up as particularly heavy functions so it didn't seem worth the increase in code & complexity.

What else could be done

After these changes, flatten and generateAndInjectStyles are still the biggest time-eaters with templates, but just behind objToCssArray when using objects. I'm not sure what's slow in generateAndInjectStyles as Chrome's profiler gives line-level timings that don't match the time spent in that function. The others can be improved, but I haven't found a nice way to do it without a bunch of code duplication yet.
Edit: This might be different now due to the recent optimizations that were just pushed to main.

Some significant perf improvements would come from transpiling to es6 to use es6 features directly, as the es5 replacements of template strings & the spread syntax slows things down quite a bit. Then, consumers of the package could transpile to es5 if needed as they're probably babeling it all anyway. On the other hand, I'm guessing most people will still end up targeting es5 themselves so these benefits won't be realised. ¯\_(ツ)_/¯

[quantizor]

Some significant perf improvements would come from transpiling to es6 to use es6 features directly, as the es5 replacements of template strings & the spread syntax slows things down quite a bit.

For me the benchmarks regressed significantly when switching the TS target to "ES2015" and updating terser to target es6.

[quantizor]

These changes look solid, thanks!