> Parsing, printing, and source map generation are all fully parallelized I thin...

mappu · on Feb 16, 2020

> I think this the major cause of speedup.

This simply can't be true. On a 4 core laptop you might expect parallelism to provide up to 4x performance. But this has 75x / 200x performance, that must come partly from other reasons.

truth_seeker · on Feb 17, 2020

First of all you didn't even care to read I also mentioned that choosing the right data structures also. ;)

You are deluded by the benchmark posted too. I terms of different build process steps that library isn't doing as much as other js build frameworks.

mappu · on Feb 18, 2020

I understood your phrase "the major cause" to mean majority reason, that couldn't be true since the remaining difference is greater. If you meant something different than that, then I misunderstood you. We both agree that the remainder of the performance (the bulk of it) must come from other reasons than parallelism.

As well as your suggestions (doing less work, choosing the right data structures) - I would also propose (A) no V8 JIT warmup time (B) no need for fstat on many node_modules files (C) fewer AST passes (D) possibility of value struct types => less boxing => lower GC pressure (E) less dynamism/no plugin architecture.