about summary refs log tree commit diff stats
path: root/html/factorial-test.png
diff options
context:
space:
mode:
authorKartik K. Agaram <vc@akkartik.com>2016-08-29 21:42:41 -0700
committerKartik K. Agaram <vc@akkartik.com>2016-08-29 21:47:13 -0700
commita800400c360c302a06c4127a34023b92244bcbf6 (patch)
tree8bbd071e3f365caec6dcd2e641d2e7667a77ee62 /html/factorial-test.png
parent45912cf8c7ffa429eab1dfb66b8851752ae7ff27 (diff)
downloadmu-a800400c360c302a06c4127a34023b92244bcbf6.tar.gz
3281 - faster incremental builds for layers
Before:

  layers -> tangle -> g++

  All changes to (C++) layers triggered recompilation of everything,
  taking 35s on my laptop, and over 4 minutes on a puny server with just
  512MB of RAM.

After:

  layers -> tangle -> cleave -> g++

  Now a tiny edit takes just 5s to recompile on my laptop.

My initial approach was to turn each function into a separate
compilation unit under the .build/ directory. That blew up the time for
a full/initial compilation to almost 6 minutes on my laptop. Trial and
error showed 4 compilation units to be close to the sweet spot. Full
compilation is still slightly slower (43s) but not by much.

I could speed things up further by building multiple of the compilation
units in parallel (the recursive invocation in 'makefile'). But that
would put more pressure on a puny server, so I'm going to avoid getting
too aggressive.

--- Other considerations

I spent some time manually testing the dependency structure to the
makefile, making sure that files aren't unnecessarily written to disk,
modifying their timestamp and triggering dependent work; that changes to
layers don't unnecessarily modify the common headers or list of globals;
that changes to the cleave/ tool itself rebuild the entire project; that
the old auto-generated '_list' files plug in at the right stage in the
pipeline; that changes to common headers trigger recompilation of
everything; etc. Too bad it's not easy to write some tests for all this.

I spent some time trying to make sure the makefile was not too opaque to
a newcomer. The targets mostly flow from top to bottom. There's a little
diagram at the top that is hopefully illuminating. When I had 700
compilation units for 700 functions I stopped printing each one of those
compilation commands, but when I backed off to just 4 compilation units
I decided to err on the side of making the build steps easy to see.
Diffstat (limited to 'html/factorial-test.png')
0 files changed, 0 insertions, 0 deletions