Can compilation times not be sped up any further?
Brett
Brett at gmail.com
Sat Oct 19 21:56:44 UTC 2019
I have a huge code base... it seems D likes to recompile
everything every time from scratch. I realize there are ways to
fix this but can't D go a step further?
Much of the code does not change. D has to compile a file per
file basis.
Could D not just has the file in such a way as to reuse parts of
previous compilations?
e.g., each function in the file could be hashed and if no changes
are made then previous code generation is used.
There should be absolutely no reason a function, specially pure
functions have to be regenerated every compilation.
By proper hashing design one should be able to almost limit
compilation to only the changes that matter.
If a file, module, package does not change it should not be
recompiled but reused. If a file's internals do not change in
specific ways then they too generally can be used.
This would probably not be too complex of a problem if integrated
in with D's parser. Each node in the AST is associated with a
hash of the text(or it could be the AST node itself in some way
but the text should do).
All code blocks need to determine what escapes and the object
code should express those escapes in some way so they can be
fixed up(which is basically global references and potential meta
changes). If the compiler monitors and records this stuff proper
then most of the work is already done.
Then it is just a matter of reading in the object code at the
right time to replace the old code.
While we can compile to individual object files this requires
user interaction. I am thinking of D having one large file that
contains all the info that it can use to reduce compilation times
by reusing information rather than regenerating. Files that do
not change text and have do not escape references do not have to
be recompiled. The compiler itself should handle this, not the
user. For individual files that do change, a more granular
approach is used. This requires every object file to also include
the granularity though for maximum speed.
More information about the Digitalmars-d
mailing list