On Tuesday, 18 November 2014 at 00:55:31 UTC, Vladimir Panteleev wrote:
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 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).

I think that's what I meant by https://github.com/CyberShadow/DBuildStat/issues/1.

As far as I know, there's no reason to think DBuildStat's output is inaccurate.

The timing noise is a slight problem, sometimes compilation is faster than parsing or justimports. Otherwise it's a really nice tool.

Reply via email to