Hacker News new | ask | show | jobs
by dale_glass 1453 days ago
How is it faster? And faster at what?
1 comments

By 'faster' I mean better build times than Make for a project of particular size. Benchmarking is going on right now, and the difference in performance is clearly visible.
Okay, but what specifically is faster?

Make is rarely a big bottleneck, except in very pathologically written projects, and when doing incremental builds. I think the main problem with big make setups is recursive make, which prevents it from having a global view on the project, and forces the main make to execute many sub-makes recursively, all of which has overhead.

The build process is faster. There are a number of algorithms running (on several threads) while building. That is where optimisation kicks in.
I suspect they are benchmarking recursive make vs recursive beast; the very first example in the readme suggests recursion
Good point. I have to say I'm wary of that, recursive make is not a good idea, and the problem can't be fixed by building a better make, because the issue is that it breaks up the dependency graph and creates build problems.

Eg, if you have src/lib, and src/bin, and the src/bin project depends on the src/lib library, then in self-contained, recursively invoked makefiles (or anything else), you won't get a correct behavior when a header in the library changes.

Other make replacements have solved this by making the dependency graph independent of the file structure. Hopefully beast does this too
What do you mean? make has no particular requirements regarding the file structure. You can write a single giant Makefile covering a directory tree with thousands of source files in various directories.