delay cmj optimizations

[anmonteiro]

fixes #464

• One disadvantage of this change is that there's a slight de-optimization when it comes to computing the necessary require calls (as they're computed before all the J.program optimizations run).
  • the reason for this is that the cmj file needs to store whether the current module is side-effectful, and that depends on other .cmj files too. So we can't just do it when emitting the .js
  • A naive fix for this is to do a 2nd pass to compute the necessary IDs. I'd like to see numbers on the dune integration before we do that, though, cc @rgrinberg @jchavarri

[anmonteiro]

The diff looks a lot better with https://github.com/melange-re/melange/pull/475/files?w=1

[jchavarri]

A naive fix for this is to do a 2nd pass to compute the necessary IDs. I'd like to see numbers on the dune integration before we do that, though

Even if the benchmarks look good, the main impact on perf for these changes is that more code will be bundled by webpack or other js bundlers unnecessarily, right? So, the trade-off will be between build speed and bundle size?

I am asking to clarify this because I believe that if one uses (module_system es6) from dune, then webpack (or any other bundler) would be able to dead-code eliminate (or "tree-shake") the unused modules. So maybe the addition of extra modules can be mitigated.

[jchavarri]

re: the deoptimization:

the reason for this is that the cmj file needs to store whether the current module is side-effectful, and that depends on other .cmj files too. So we can't just do it when emitting the .js

Would it be possible to store at cmj-generation time the other cmjs info required to calculate the "purity" at cmj-time, and use it later at js-generation time?

[jchavarri]

What does "coercion" mean in this context?

[anmonteiro]

Would it be possible to store at cmj-generation time the other cmjs info required to calculate the "purity" at cmj-time, and use it later at js-generation time?

this is a good idea. I'll play with it this week.