Speeding up importing Phobos files

H. S. Teoh hsteoh at quickfur.ath.cx
Mon Jan 21 21:52:01 UTC 2019


On Mon, Jan 21, 2019 at 04:38:21PM -0500, Steven Schveighoffer via Digitalmars-d wrote:
[...]
> One note -- I don't think modules like std.datetime were split up for
> the sake of the compiler parsing speed, I thought they were split up
> to a) avoid the insane ddoc generation that came from it, and b)
> reduce dependencies on symbols that you didn't care about. Not to
> mention that github would refuse to load std.datetime for any PRs :)

And also, I originally split up std.algorithm (at Andrei's protest)
because it was so ridiculously huge that I couldn't get unittests to run
on my PC without dying with out-of-memory errors.


> But it does help to consider the cost of finding the file and the cost
> of using the file separately, and see how they compare.
[...]

I still think a lot of this effort is misdirected -- we're trying to
hunt small fish while there's a shark in the pond.  Instead of trying to
optimize file open / read times, what we *should* be doing is to reduce
the number of recursive templates heavy-weight Phobos modules like
std.regex are using, or improving the template expansion strategies
(e.g., the various PRs that have been checked in to replace O(n)
recursive template expansions with O(log n), or replace O(n^2) with
O(n), etc.).  Or, for that matter, optimizing how the compiler processes
templates so that it performs better.

Optimizing file open / file read in the face of these much heavier
components in the compiler sounds to me like straining out the gnat
while swallowing the camel.


T

-- 
Жил-был король когда-то, при нём блоха жила.


More information about the Digitalmars-d mailing list