On Wednesday, 4 January 2017 at 12:44:08 UTC, Andrei Alexandrescu
wrote:
How large was the codebase? Thx! -- Andrei
wc reports about 80,000 lines. But it isn't line count that
affects build speed in D: it is the content of those lines.
When I optimized it, the source code actually got *bigger*, but I
simplified templates and moved some stuff to runtime functions
which build much, much faster than complicated template+CTFE
instantiations.
See, the program used a lot of code generation so I'd just add a
function to the class and all the web API and most the HTML
components would be auto-generated from the function signature.
By the time the D program was up to 10,000 lines, we already had
more relevant functionality than the 100,000 line PHP program we
were migrating away from, mostly thanks to the more efficient
abstractions and generating boilerplate automatically. (Though,
granted, the php did some stuff we didn't care about too, the
feature sets were mostly comparable.)
However, adding a one line function to the source could result in
a dozen templates being instantiated, which slows compile and
makes for some huge binaries. When I changed it, it would do some
metadata generation in the template, then pass off to as many
reused instantiations as possible (so instead of
generateFunction!foo doing everything, it would forward to
generateFunctionArgumentCode!(ParameterType!foo) (well, we didn't
have ParameterType back then, std.traits wasn't even around IIRC
until after like 2012 and I did the bulk of this in 2010, but my
homemade code did the same thing). Then, the compiler can reuse
the same thing for common types like int and string. Also, these
would generate data tables that a runtime function could load
instead of *being* the whole function, cutting the generated code
down significantly.)
Actually, I started all templated, then moved to a hybrid
template + TypeInfo-like setup for various reasons... something
to keep in mind as we talk about heavily templating druntime...
(The performance difference at runtime was negligible, though I
didn't dive into it much, since the performance of most the code
was never under pressure; when things got slow, it was because of
a few specific functions. My CSS thing was slow, so I cached it,
problem solved. A few database queries were slow, so I fixed the
SQL, problem solved. The gains from fixing those 10-line hotspots
were always the major fixes we needed.)
