AST files instead of DI interface files for faster compilation and easier distribution

[Don Clugston]

On 13/06/12 16:29, Walter Bright wrote:
> On 6/13/2012 1:07 AM, Don Clugston wrote:
>> On 12/06/12 18:46, Walter Bright wrote:
>>> On 6/12/2012 2:07 AM, timotheecour wrote:
>>>> There's a current pull request to improve di file generation
>>>> (https://github.com/D-Programming-Language/dmd/pull/945); I'd like to
>>>> suggest
>>>> further ideas.
>>>> As far as I understand, di interface files try to achieve these
>>>> conflicting goals:
>>>>
>>>> 1) speed up compilation by avoiding having to reparse large files over
>>>> and over.
>>>> 2) hide implementation details for proprietary reasons
>>>> 3) still maintain source code in some form to allow inlining and CTFE
>>>> 4) be human readable
>>>
>>> (4) was not a goal.
>>>
>>> A .di file could very well be a binary file, but making it look like D
>>> source enabled them to be loaded with no additional implementation work
>>> in the compiler.
>>
>> I don't understand (1) actually.
>>
>> For two reasons:
>> (a) Is lexing + parsing really a significant part of the compilation
>> time? Has
>> anyone done some solid profiling?
>
> It is for debug builds.

Iain's data indicates that it's only a few % of the time taken on 
semantic1().
Do you have data that shows otherwise?

It seems to me, that slow parsing is a C++ problem which D already solved.

>
>> (b) Wasn't one of the goals of D's module system supposed to be that
>> you could
>> import a symbol table? Why not just implement that? Seems like that
>> would be
>> much faster than .di files can ever be.
>
> Yes, it is designed so you could just import a symbol table. It is done
> as source code, however, because it's trivial to implement.

It has those nasty side-effects listed under (3) though.