On Friday, 17 June 2016 at 06:18:28 UTC, H. S. Teoh wrote:
On Fri, Jun 17, 2016 at 05:41:30AM +0000, Jason White via Digitalmars-d-announce wrote: [...]
Where Make gets slow is when checking for changes on a ton of files. I haven't tested it, but I'm sure Button is faster than Make in this case because it checks for changed files using multiple threads. Using the file system watcher can also bring this down to a near-zero time.


IMO using the file system watcher is the way to go. It's the only way to beat the O(n) pause at the beginning of a build as the build system scans for what has changed.

See, I used to think that, then I measured. tup uses fuse for this and that's exactly why it's fast. I was considering a similar approach with the reggae binary backend, and so I went and timed make, tup, ninja and itself on a synthetic project. Basically I wrote a program to write out source files to be compiled, with a runtime parameter indicating how many source files to write.

The most extensive tests I did was on a synthetic project of 30k source files. That's a lot bigger than the vast majority of developers are ever likely to work on. As a comparison, the 2.6.11 version of the Linux kernel had 17k files.

A no-op build on my laptop was about (from memory):

tup: <1s
ninja, binary: 1.3s
make: >20s

It turns out that just stat'ing everything is fast enough for pretty much everybody, so I just kept the simple algorithm. Bear in mind the Makefiles here were the simplest possible - doing anything that usually goes on in Makefileland would have made it far, far slower. I know: I converted a build system at work from make to hand-written ninja and it no-op builds went from nearly 2 minutes to 1s.

If you happen to be unlucky enough to work on a project so large you need to watch the file system, then use the tup backend I guess.

Atila

              • R... H. S. Teoh via Digitalmars-d-announce
              • R... Jason White via Digitalmars-d-announce
              • R... Atila Neves via Digitalmars-d-announce
              • R... Fool via Digitalmars-d-announce
              • R... H. S. Teoh via Digitalmars-d-announce
              • R... Jason White via Digitalmars-d-announce
              • R... H. S. Teoh via Digitalmars-d-announce
              • R... Jason White via Digitalmars-d-announce
              • R... H. S. Teoh via Digitalmars-d-announce
              • R... Jason White via Digitalmars-d-announce
              • R... Atila Neves via Digitalmars-d-announce
              • R... H. S. Teoh via Digitalmars-d-announce
              • R... Dicebot via Digitalmars-d-announce
    • Re: Button: A fast, co... Edwin van Leeuwen via Digitalmars-d-announce
  • Re: Button: A fast, correct... jmh530 via Digitalmars-d-announce

Reply via email to