Speeding up importing Phobos files

[Andrei Alexandrescu]

On 6/10/19 4:54 AM, Amex wrote:
> 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%.

Not if that 1% costs 99% of your budget.