You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking at the wallclock time, in this stress test the performance was 50%
in my actual test-suite the performance dropped by 20%.
Looking at the flamegraph in detail, JSON.stringify/JSON.parse is 800% faster in isolation.
Also, from these flames, it looks like the other huge CPU hog is my naively implemented language parser using the parsimmon framework :)
It would be cool if benchmarks can be added and this library can be performance tuned.
Once I start performance tuning my application, I can optimize the copy() function and contribute the code back (it might make simplification trade-offs for performance... and no longer be "universal")
The text was updated successfully, but these errors were encountered:
Thanks for all the details. I'll dig into it when I can.
Off the top of my head, the FakeMap that gets used if you don't have native maps available probably isn't performant, and moveProps is costly in the name of correctness.
Trying gutting moveProps to just do a for in loop and not worry about symbols/property descriptor nonsense is the first thing to look at to sacrifice completeness for perf.
I replaced two lines in my code base from:
to
And it increased the runtime of test suite from 4 seconds to 5 seconds.
My code base is a type checker, the main place i use universalCopy() is to copy the type definition files AST, which is a large data structure.
JSON.parse(JSON.stringify())
:universal-copy
:I also created two flamegraphs:
Also, from these flames, it looks like the other huge CPU hog is my naively implemented language parser using the
parsimmon
framework :)It would be cool if benchmarks can be added and this library can be performance tuned.
Once I start performance tuning my application, I can optimize the copy() function and contribute the code back (it might make simplification trade-offs for performance... and no longer be "universal")
The text was updated successfully, but these errors were encountered: