diff options
author | Kartik K. Agaram <vc@akkartik.com> | 2016-08-29 21:42:41 -0700 |
---|---|---|
committer | Kartik K. Agaram <vc@akkartik.com> | 2016-08-29 21:47:13 -0700 |
commit | a800400c360c302a06c4127a34023b92244bcbf6 (patch) | |
tree | 8bbd071e3f365caec6dcd2e641d2e7667a77ee62 /static_dispatch.mu | |
parent | 45912cf8c7ffa429eab1dfb66b8851752ae7ff27 (diff) | |
download | mu-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 'static_dispatch.mu')
0 files changed, 0 insertions, 0 deletions