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.
