goober
goober copied to clipboard
Stringify object using Object.entries instead of separated function
Shaved off quite a few bytes by removing the stringify
function and using Object.entries
instead. I don’t know how this affected performance, running the benchmark did not give me the opportunity to evaluate the difference.
Also now this stringify returns a slightly different result. Example object:
{
"value": 10
}
Old version: value10
My version: value,10
This affected the hash, so I had to edit the tests
Size comparison
Before:Wrote 1183 B: goober.cjs.gz
1079 B: goober.cjs.br
Wrote 1188 B: goober.esm.js.gz
1085 B: goober.esm.js.br
Wrote 1257 B: goober.umd.js.gz
1137 B: goober.umd.js.br
Wrote 1188 B: goober.modern.js.gz
1085 B: goober.modern.js.br
After:
Wrote 1167 B: goober.cjs.gz
1062 B: goober.cjs.br
Wrote 1173 B: goober.esm.js.gz
1067 B: goober.esm.js.br
Wrote 1239 B: goober.umd.js.gz
1120 B: goober.umd.js.br
Wrote 1173 B: goober.modern.js.gz
1067 B: goober.modern.js.br
This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.
🔍 Inspect: https://vercel.com/cristianbote/goober-rocks/4x3LCsWFPTbu2ZE9MDfS13WmSs16
✅ Preview: https://goober-rocks-git-fork-realpeha-remove-strin-73dd42-cristianbote.vercel.app
This pull request is automatically built and testable in CodeSandbox.
To see build info of the built libraries, click here or the icon next to each commit SHA.
Latest deployment of this branch, based on commit b8c8503bcc392b3e6cbd0b2da1cb4fdb0915e5b4:
Sandbox | Source |
---|---|
Vanilla | Configuration |
Thanks @RealPeha! Will look into the perf to see if there are any regressions.
Replaced Object.entries(compiled) + ''
with Object.entries(compiled) + 0
and shave 1 byte for umd and cjs bundles
@RealPeha thank you so much for your work on this! 🙏 I appreciate it!
Looked at the perf scores and this is the breakdown:
For node env:
> NODE_ENV=production node benchmarks/perf.cjs
Starting: styled:object
▸ goober (Object.entries) x 135,277 ops/sec ±3.09% (76 runs sampled)
▸ goober x 190,528 ops/sec ±2.55% (84 runs sampled)
Fastest is: goober
Starting: styled:tagged
▸ goober (Object.entries) x 206,359 ops/sec ±1.73% (92 runs sampled)
▸ goober x 210,974 ops/sec ±1.61% (90 runs sampled)
Fastest is: goober
Starting: styled:array
▸ goober (Object.entries) x 131,862 ops/sec ±2.71% (87 runs sampled)
▸ goober x 187,293 ops/sec ±2.30% (87 runs sampled)
Fastest is: goober
Changed locally the test so it'll head-to-head the changed version -- the one with Object.entries, with the regular master one. This is a pretty decent regression in terms of perf. This will affect SSR performance or build durations.
Now in terms of browser:
goober (Object.entries) Mount deep tree (500) = 11.28 ±01.11 ms
goober (Object.entries) Mount deep tree (500) = 11.76 ±00.51 ms
goober (Object.entries) Mount deep tree (500) = 11.66 ±00.61 ms
goober Mount deep tree (500) = 11.57 ±00.53 ms
goober Mount deep tree (500) = 11.53 ±00.52 ms
goober Mount deep tree (500) = 11.49 ±00.66 ms
There really isn't much of a difference.
What are your thoughts on this? On one hand goober does get smaller but at the cost of perf degradation on node env and on the other the browser based rendering is just fine.
I think that performance should be a priority, and reducing the bundle by a couple of bytes does not provide any benefit. In any case, I'm doing this for fun and I have a more ideas on how to shave off a couple of bytes, so there will be new PRs soon 😉