Tracking compilation times and memory usage by commit

[Laeeth Isharc]

On Sunday, 30 December 2018 at 13:46:46 UTC, H. S. Teoh wrote:
> On Sun, Dec 30, 2018 at 01:25:33PM +0000, Guillaume Piolat via 
> Digitalmars-d wrote:
>> On Saturday, 29 December 2018 at 09:29:30 UTC, Walter Bright 
>> wrote:
>> > http://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/
>> 
>> It says:
>> 
>> > C++ compilation times have been a source of pain in every
>> > non-trivial-size codebase I’ve worked on. Don’t believe me? 
>> > Try
>> > building one of the widely available big codebases (any of:
>> > Chromium, Clang/LLVM, UE4 etc will do). Among the things I 
>> > really
>> > want out of C++, “solve compile times” is probably #1 on the 
>> > list,
>> > and has been since forever.
>> 
>> I agree, it has been #1 problem with C++ in years, and only 
>> getting worse.
>> 
>> There is the theory (D builds fast) and the application (DUB 
>> often
>> negate the advantage, you need to avoid templatitis).
>
> D theory sounds all good and all, but in practice you have 
> warts like dub (one big reason I stay away from it -- though 
> based on what Sonke said recently, performance may have 
> improved since I last checked), std.regex (after the last big 
> refactor, something Really Bad happened to its compile times -- 
> it didn't used to be this bad!), std.format (a big hairball I 
> haven't dared to look too deeply into), and a couple of others, 
> like various recursive templates elsewhere in Phobos. And also 
> std.uni's large templated internal tables, which may be (part 
> of?) the common cause of compile-time slowdowns in std.format 
> and std.regex.
>
> T

Perhaps we should implement CyberShadow's idea into the build 
infrastructure.  Works quite nicely with etsy statsd - see 
library from Burner.

https://blog.thecybershadow.net/2015/05/05/is-d-slim-yet/


Laeeth