Speeding up importing Phobos files

KnightMare black80 at bk.ru
Sat Jun 8 10:35:58 UTC 2019


On Saturday, 8 June 2019 at 06:29:16 UTC, Amex wrote:
> Why not compile phobos to an object file? Basically store the 
> AST directly in to a file and just load it. Phobos never 
> changes so why recompile it over and over and over and over?
>
+1 for AST.
and even more: AST-builder make as RT-module. bonuses:
- storing packages as AST-asssembly: no parsing/building-AST for 
packages, only for user code - that increase compile speed.
- can be stored more compacted than source coz words (var names, 
keywords) are repeated many times through source. and many source 
files can be stored in one "assembly/AST-package" with one 
string-literal-table, with one typeinfo-table.
- DSL metaprogramming moves to a higher level: steps "parsing DSL 
- generate D code - parse D code - generate AST" will become 
"parsing DSL - generate AST" that increase compiling time and 
helps to appear many DSL for JSON/XML/DB-schemas, and will be 
used for UI description (same as QML) and many more.
- LDC(dunno with DMD/GCC) can generate code dynamically at 
runtime already (probably it stores LLVM-IR now) then can 
generate code from AST in runtime (not only in compile time for 
metaprogramming): same bonuses/possibilities as Expression Trees 
and Scripting for .NET. Yes, Dlang can use 3rd parties script 
engines but they are not native - interop is not free, many 
wrappers/dispatchers to and from, two different GC, failed with 
threads and TLS, so its for a toy now not more. With native 
scripting absent interop at all, execution speed as compiled C++ 
(LLVM generate fast code), one GC for all objects, one thread 
pools with same TLS..

I see only one minus: dont use AST for DRT and as module itself 
for programmers.
In any case AST-builder already exists in compiler, just bring it 
outside to public space and allow store packages as AST too.


More information about the Digitalmars-d mailing list