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.
