Aside from running dune's internal profiler, are there any other ways to get insight into which bits of an OCaml build are slowing down a particularly long build, and why they do? Anything from a list of things to avoid to reading material to automated tooling (or even pointers as to how to interpret the traces coming out of the dune profiler!) would be great 
.
I currently have a medium-sized project compile that’s taking about 2.5min to build (using 4.07.1 ocamlopt), and it feels like it certainly shouldn’t be taking that long. Pointing chromium at the dune profile reveals that almost a minute of that is PPX rewrites (I’m currently pulling in ppx_derivers.std and ppx_jane), and the rest is almost entirely just a lot of small, half-parallelised runs on files.
There are a few files that seem to be taking longer (which looks like it’s directly proportionate to the amount of code involved, though the most egregious ones are ones that contain functors producing large modules with other modules included within), and a few instances where the build is sequentialised due to everything depending on one library whose build depends on one module (and, on the flip side, sometimes I get full parallelism of 4 jobs on 4 cores), but I can’t draw many obvious conclusions as to what I’m doing wrong/suboptimally.
EDIT: odoc builds on the same tree slow to a literal crawl, too, so I figure there’s something that’s genuinely nasty in there, but I’m not well-equipped to find out what.
EDIT 2: I have a sneaky suspicion the ‘genuinely nasty’ behaviour is a mountain of transitive module type include, which seems to be making odoc’s output for the affected types snowball to ludicrous (~300MB a file) proportions. Ouch.
8 posts - 5 participants