Building the compiler in 2 seconds with `dmd -i`

H. S. Teoh hsteoh at qfbox.info
Fri May 19 16:58:56 UTC 2023


On Fri, May 19, 2023 at 04:48:01PM +0000, max haughton via Digitalmars-d wrote:
[...]
> The reason why dmd -i works better than one might initially assume is
> that:
> 
> 1. importing druntime is too slow.
> 2. Semantic analysis is not shared between parallel compiler
> invocations
> 
> Both of which result in a lower bound on the time taken regardless of
> parallelism
> 
> 2.0 seconds is still way way way too slow IMO. Iteration should
> ideally be instant, tests running before you blink after saving the
> file. That's the benefit of incremental compilation, ideally you just
> have it watch the source code and reuse stuff that didn't change.

The current architecture of DMDFE just doesn't lend itself to this, what
with mutating the AST as the compilation goes on, and all that.  If you
want to do this, you're probably looking at reimplementing the compiler
from scratch to be a live compiler service, rather than a batch process.
It will have to hold the program AST in memory and be able to replace
and recompile parts of it upon request (e.g. when a source file
changes).

Keep in mind that replacing and recompiling parts of the AST may not be
as simple as it sounds, because other parts of the AST (e.g., other
modules) may have references to the old AST, so all of those have to be
updated as well.  The AST structures must be designed to handle this
kind of operation; I highly doubt whether the current DMDFE AST
structures can handle something like this at all.


T

-- 
Guns don't kill people. Bullets do.


More information about the Digitalmars-d mailing list