[Modules] Faster compilation speed or better diagnostic messages?

[vvassilev]

Hi all,

Thanks for bringing this up. Our use of modules is mostly for reflection information purposes where the load time and the peak memory use basically define if we should adopt modules or not.

@iains

AFAIR, we do as much ‘lazily’ as we can at the moment (e.g. so that we should not read a function body if we do not need it - although it still occupies space unnecessarily).

Yes we do most of the work lazily with several notable exceptions. Currently, the way we model the source locations in clang and the ASTReader is problematic. It comes from just a single line in clang where we reserve huge chunks for memory for the source location of eventually read entities. However fixing this would be very hard and might need to rework the source location management. We have tried workarounds such as using sparse vectors to delay the pre-allocations but without a great success. Reworking the source locations modelling in clang will be probably a good thing since it is a bit inefficient now. We might be able to use some sort of binary tree to model them. That issue is a major blocker if we build a module for a library which has a lot of token-generating header files such as boost preprocessor (or in fact most of the large boost libraries).

Another problem is that we eagerly deserialize template specializations upon module load. That is because we need to make the selection and possibly implicitly instantiatate. That results in a lot of redundant deserializations even for standard modules such as the one for libstdc++ since we have tons of specializations. In fact the this issue might be easier to fix and less intrusive. A very old solution is here ⚙ D41416 [modules] [pch] Do not deserialize all lazy template specializations when looking for one. and I will update it next week since I think I screwed up rebasing…

A major unsolved issue is the eager loading of types from the ASTReader. Some types are huge such as the template specialization types. That is, the way we load types eagerly here. Unfortunately, I do not have a plan how to fix this.

A long standing optimization is reducing the update record calls in many contexts where we do not need them…

These are the major issues we see on our production workflows so far.

@bcardosolopes

I’m in favor of a “better diagnostic” story for modules, specially for more “default” user friendly compiler invocations, even if that means a perf trade-off. We also want to harvest better build speeds, it’s inevitable. My suggestion is for such default mode to be diagnostic-centric “default serialization + lazy deserialization on lookup error (as mentioned by Corentin)” and a compiler flag (perhaps a cc1 based) that disables that in favor of build speeds - experience with that flag might tell us over time if the default should change.

I would like to second that if we manage to make a module loading a no-op which does not seem to be far from what I understand.