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