Speeding up importing Phobos files
Amex
Amex at gmail.com
Mon Jun 10 08:54:26 UTC 2019
On Sunday, 9 June 2019 at 19:51:14 UTC, Andrei Alexandrescu wrote:
> On 6/9/19 2:52 PM, Nick Sabalausky (Abscissa) wrote:
>> I was just speaking in general about the overall strategy you
>> were promoting: Preferring to forego stopgap measures in the
>> interims before correct solutions are available. (Unless I
>> misunderstood?)
>
> I can tell at least what I tried to do - use good judgment for
> each such decision. More often than not I propose workarounds
> that the community turns its nose at - see e.g. the lazy
> import. To this day I think that would have been a great thing
> to do. But no, we need to "wait" for the full lazy import that
> will never materialize.
Has anyone merged all of phobos in to one large file, removed all
the modules(or modify the compile to handle multiple modules per
file and internally break them up) and see where the bottle neck
truly is? Is it specific template use or just all templates? Is
there a specific template design pattern that is often used that
kills D?
And alternatively, break phobos up in to many more files, one per
template... and see the performance of it.
Maybe there is specific performance blocks in the compiler and
those could be rewritten such as parallel compilation or
rewriting that part of the compiler to be faster or whatever..
What I'm seeing is that it seems no one really knows the true
culprit. Is it the file layout or templates? and each issue then
branches...
After all, maybe it is a combination and all the areas could be
optimized better. Even a 1% increase is 1% and if it stacks with
another 1% then one has 2%. A journey starts with the first 1%.
More information about the Digitalmars-d
mailing list