Proposed improvements to the separate compilation model

[Don]

Andrei Alexandrescu wrote:
> On 7/23/11 1:53 PM, Andrej Mitrovic wrote:
>> Isn't the biggest issue of large D projects the problems with
>> incremental compilation (e.g.
>> https://bitbucket.org/h3r3tic/xfbuild/issue/7/make-incremental-building-reliable), 
>>
>> optlink, and the toolchain?
> 
> The proposed improvement would mark a step forward in the toolchain and 
> generally in the development of large programs. In particular, it would 
> provide a simple means to decouple compilation of modules used together. 
> It's not easy for me to figure how people don't get it's a net step 
> forward from the current situation.
> 
> Andrei

Personally I fear that it may be too much cost for too little benefit.

The role of .di files for information hiding is clear. But it's not _at 
all_ obvious to me that .di files will provide a significant improvement 
in compilation speed. Do we actually have profiling data that shows that 
parsing is the bottleneck?

It's also not clear to me that it's a "simple means to decouple 
compilation of modules" -- it seems complicated to me.

As far as performance goes, it would seem much simpler to just cache the 
symbol tables (similar to precompiled headers in C++, but the idea works 
better in D because D has an actual module system). That would give 
faster compilation times than .di files, because you'd also be caching 
CTFE results.