THE FOLD / CO-OP / THE MERGE / THE INCREMENTAL BUILD
THE INCREMENTAL BUILD
a pricing schedule nobody wrote deliberately
1 WHAT IT IS · WHAT IT DOES · FACT OR FICTION
Rebuild only what depends on what changed. The saving is real, and it is not evenly distributed — some files cost almost nothing to edit and others cost nearly the whole project.
LIT verified live on a 7-target graph. Changing test.c rebuilds 1 target — 14.3%. Changing parse.c rebuilds 4. Changing util.h or config.h rebuilds 6 — 85.7% of everything, from editing one header. The ratio between the worst edit and the best is 6.00, and nothing about the files themselves says which is which.
LIT verified live on a 7-target graph. Changing test.c rebuilds 1 target — 14.3%. Changing parse.c rebuilds 4. Changing util.h or config.h rebuilds 6 — 85.7% of everything, from editing one header. The ratio between the worst edit and the best is 6.00, and nothing about the files themselves says which is which.
2 HOW IT WAS WEAVED · AI + HUMAN
The rebuild set is the reverse reachability closure of the changed node; that is all an incremental build is, and everything else is deciding when a node counts as changed.
AVAN (AI) reports the spread rather than an average. A mean rebuild cost across the project is a number nobody experiences — what people experience is the header, and the header is 6× the cheapest edit in a graph this small.
AVAN (AI) reports the spread rather than an average. A mean rebuild cost across the project is a number nobody experiences — what people experience is the header, and the header is 6× the cheapest edit in a graph this small.
3 ONE DIMENSION
Four edits, four very different bills.
4 TWO DIMENSIONS · INTERACTIVE
Touch a file and watch the graph light up.
5 THREE DIMENSIONS + AVAN’S INVERSE
The green forward object: one edit, and what follows it.
AVAN’s addition (the inverse-companion): the forward reading is that incremental builds save time by rebuilding less. The inverse is that they make the cost of an edit a property of the architecture rather than of the edit. Changing one line in config.h and one line in test.c are the same act, and the graph charges 6× more for one of them. Read backwards, the dependency graph is a pricing schedule nobody wrote deliberately, and every header included “just in case” sets a rate that gets paid on every future edit.
LIT on a 7-target graph, changing test.c rebuilds 1 target which is 14.3%, changing parse.c rebuilds 4, and changing util.h or config.h rebuilds 6 - 85.7% of everything, from editing one header - so the ratio between the worst edit and the best is 6.00 and nothing about the files themselves says which is which
FIG The rebuild set is the reverse reachability closure of the changed node; that is all an incremental build is, and everything else is deciding when a node counts as changed. AVAN reports the spread rather than an average, because a mean rebuild cost across the project is a number nobody experiences - what people experience is the header, and the header is 6 times the cheapest edit in a graph this small.
FIG The rebuild set is the reverse reachability closure of the changed node; that is all an incremental build is, and everything else is deciding when a node counts as changed. AVAN reports the spread rather than an average, because a mean rebuild cost across the project is a number nobody experiences - what people experience is the header, and the header is 6 times the cheapest edit in a graph this small.
◆ sealed .dlw.fold → folded to ROOT_0 · a sphere of THE MERGE · David Lee Wise (ROOT0), with AVAN