3 ms·
> But we're presumably talking about two types of performance: Agreed, and you only need to look at C++ linkers for proof this. LTCG can take minutes (or even
by maccard 6y ago
> But we're presumably talking about two types of performance:
Agreed, and you only need to look at C++ linkers for proof this. LTCG can take minutes (or even hours) for marginal gains.
That said, this entire article is about migrating the development builds and still being painfully slow. The links I shared to esbuild point to building release-able bundles, I.E. "Optimised". And let's be honest, the optimised bundles here (i.e. the output of webpack) aren't performing inlining, constant folding, expression simplification, dead code analysis, or anything of the sort, they're doing some fairly rudimentary file IO. Only the most invasive optimisations (whole program optimisation) should explain the orders of magnitude of a difference.
The reason they're slow is because they're written in JS, single threaded, with no considerations for performance. As esbuild has proven, rewriting in go with consideration for perf can provide a 100x speedup!
> but realistically does it exist right now?
Yes, it does it's esbuild and I linked to it in my comment above!
> That's probably a trite/obvious argument, but it's worth mentioning nonetheless.
Honestly it's probably the truth but it's insane how we've managed to get here!