Getting around startup memory spike #711
Conversation
There was a problem hiding this comment.
Would it be possible to use a text encoding more compact than hex?
Metadata types are quite big in general, and having a small change in encoding can have a significant impact on bundle sizes.
Also, the difference in memory usage with the reproduction case is in the same order of magnitude: The smallest V8's memory size I could do with the current version is 165mb, whereas this fix brings it down to 120mb.
Esbuild doesn't want to fix evanw/esbuild#3894, and we're hitting memory limits again, after upgrading papi to latest version. This allows us to bypass binary loader and get back to normal memory usage during application startup.
Okay, I've copied base64 decoder from esbuild itself, should be just the same now
crank it up to five chains, it'll take 380mb for current version and 130mb for my fix |
mutantcornholio
force-pushed
the
yuri/startup-memory-workaround
branch
from
96dc797
to
d86c46f
Compare
Esbuild doesn't want to fix evanw/esbuild#3894, and we're hitting memory limits again, after upgrading papi to latest version.
This allows us to bypass binary loader and get back to normal memory usage during application startup.
I've created a small repro which fails with OOM on current papi version, but works fine with my changes.
papi-repro.tar.gz
Fixes #654