Blog Post - Reducing vibe.d turnaround time (Part 2 Less Compiling)
Vladimir Panteleev via Digitalmars-d-announce
digitalmars-d-announce at puremagic.com
Mon Nov 17 16:55:30 PST 2014
On Tuesday, 18 November 2014 at 00:41:42 UTC, Martin Nowak wrote:
> Second part on my series to reduce vibe.d turnaround time.
> In this part we'll reduce compilation time by 60%.
>
> https://code.dawg.eu/reducing-vibed-turnaround-time-part-2-less-compiling.html
From the post:
> I converted the resulting timings into the graph below but only
> included the upper quartile sorted by compilation time. Take
> the numbers with a salt of grain because they are based on
> separate compilation. Usually you’ll compile multiple modules
> (e.g. a library) at once which allows the compiler to reuse
> module passes when something is imported multiple times.
I think I need to think of a different way to present imported
module times in DBuildStat output, because the current way is
unintuitive and easy to misinterpret. The blue bars of each
module should not be summed together, they're there only to give
you a clue of how much (in compiler time) a certain module is
importing - but the time will be shared for all modules in
non-incremental compilation (you can think of it as if the blue
bars are actually overlapping each other). The total time will be
proportional to the sum of the lengths of the non-blue bars
(red/orange in Martin's blog post, green/red in DBuildStat's SVG
visualizer).
As far as I know, there's no reason to think DBuildStat's output
is inaccurate, you just have to know how to interpret the data.
More information about the Digitalmars-d-announce
mailing list