[wg-camlp4] benchmarks

[Thomas Gazagnaire]

> - Running AST rewriters as independent processes adds about 7% of compilation time with ocamlopt.opt
> - If we run a single process without marshaling the AST between rewriters, the marginal cost goes below 1% per rewriter.  (This is, basically, the cost of iterating over the AST with objects, matching over each expression to find extension "markers", and rebuilding a deep copy of the AST.)
> - This can be reduced a lot with proper configuration of the GC (down to about 0.3% of compilation time with ocamlopt.opt, with the same GC config).
> - It would be interesting to do some timings when dynlinking a lot of different .cmxs plugins in ppx_drivers.

Thanks for the detailed explanation. This sounds like very good results and strong arguments to replace the complex camlp4 beast by something lighter.

I quite like the idea of having AST rewriter hooks in compiler libs to create easy-to-use compiler variations.

--
Thomas


> (If we link the rewriters statically with a custom version of the compiler itself, assuming a new hook in the compiler allows to plug AST rewriter, we would only pay the marginal cost < 1%.)
> 
> For a code base like Jane Street's where many "extensions" have to be used everywhere, I suspect that the "independent" ppx processes might become an issue (or maybe not, if compared to camlp4), but the following solutions would work:
> 
> - Statically linking a "big rewriter" called with -ppx.
> - Statically linking a version of ocamlopt.opt + all rewriters.
> - Dynamically linking all rewriters with a single ppx driver (to be confirmed, there would be a small overhead for the dynamic linking itself in addition to the 0.3% marginal cost above).
> 
> 
> 
> 
> Alain
> _______________________________________________
> wg-camlp4 mailing list
> wg-camlp4 at lists.ocaml.org
> http://lists.ocaml.org/listinfo/wg-camlp4