Speeding up importing Phobos files

[Nick Sabalausky (Abscissa)]

On 6/9/19 3:56 AM, Andrei Alexandrescu wrote:
> On 6/8/19 6:19 PM, Nick Sabalausky (Abscissa) wrote:
>> On 6/8/19 10:48 AM, Andrei Alexandrescu wrote:
>>> On 6/8/19 5:23 AM, H. S. Teoh wrote:
>>>> It should have been. The old std.algorithm was a monster of 10,000 LOC
>>>> that caused the compiler to exhaust my RAM and thrash on swap before
>>>> dying horribly, when building unittests. It was an embarrassment.
>>>
>>> The appropriate response would have been (and still is) to fix the 
>>> compiler. A more compact working set will also accelerate execution 
>>> due to better locality.
>>
>> Sheesh, this is *exactly* the sort of "Perfection is the enemy of the 
>> good" foot-shooting that's been keeping D years behind where it could be.
> 
> I did allow the breaking up of std.algorithm.

Yes, and that's definitely good - after all, it gave us a stopgap fix 
for the immediate problem, while the proper solution is(was?) still 
in-the-works. Besides, much of the time, once a "proper solution" does 
become available, the old stopgap can then be rolled back/deprecated if 
necessary. (Not sure whether or not rolling back the change would be 
appropriate in std.algorithm's case, but ATM, I'm not too terribly 
concerned with that either way.)

To clarify, in my previous post, I wasn't really talking *specifically* 
about the breaking up of std.algorithm (after all, like you said, that 
DID go through). 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?)

(Of course, in the cases where a correct solution is just as 
quick-n-simple as any stopgap, well, then yes, certainly the correct 
solution should just be done instead. Again, not saying this was or 
wasn't the case with the breaking up of std.algorithm, I'm just speaking 
in general terms.)