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