GNU make with depcache/some general build speed up tips/three LibreOffice GNU make forks considered harmful
Bjoern Michaelsen
bjoern.michaelsen at canonical.com
Tue Feb 18 16:57:39 CET 2014
Hi,
as promised at FOSDEM here is the proof-of-concept for the dependency caching
stuff for GNU make. To get it do:
git clone https://github.com/bjoernmichaelsen/gnu-make-depcache.git gnu-make
git checkout feature/depcache
git clean -dfx
autoreconf -i && ./configure && make update && make && make check
and then point the "export GNUMAKE=" line in your config_host.mk to the
generated binary. Here is what is there:
- cache generation
- cache usage
- basic test harnish
- backwards compatible implementation (triggering on .FEATURES variable)
Here is what is missing:
- handling missing dependency files (gotta look into that one)
- documentation
- the depcache isnt platform-independant
Below are the numbers -- note that the 32 seconds are on the same machine as
the numbers I presented at FOSDEM, but instead of doing measurements on the
bus, I did so in a calm place at home.
Conclusions so far:
- measuring IO performance on a notebook is tricky, doing so on the bus to
FOSDEM is insane
- unplugging your power supply can ~half your IO speed on a SSD/notebook even
on Linux
- Maintainer Mode is slow, it does a lot of extra sanity checks at runtime
if you use a self compiled GNU make you really want:
https://github.com/bjoernmichaelsen/gnu-make-depcache/commit/00bc33b760cc54a270418212af2d4750808b91f9
- tmpfs has no additional advantage when you do depcaching
- we are below 11 seconds for build-nocheck on a 3 year old dev notebook, no
need to push this further
I would really love to hear, if the depcache does have any impact at all on:
- slow HDDs (not ssds)
- other platforms (esp. slow Windows)
To test this, do a full build, get the depcache branch and build it as
described above, and then edit the "export GNUMAKE" line in your config_host.mk
to point to the modified make executable.
For the Linux build, its not worth fixing the remaining issues -- but if
Windows gains from this, I would have a look.
Best,
Bjoern
P.S.: We current have two gnu make forks in dev-tools, one in the gnu-make-lo
repository on gerrit, were one cant push to. Such a mess. When nobody
protests, I will delete the copies in dev-tools and make the gnu-make-lo
repository writable. Whatever forking had been done there and is still of
value needs to be pushed on proper branches there then.
build times:
distro provided GNU make 3.81, power supply unplugged, build on SSD:
real 0m32.942s
distro provided GNU make 3.81, power supply plugged, build on SSD:
real 0m17.071s
GNU make 4.0 -- maintainer mode, power supply plugged, build on SSD:
real 0m18.469s
GNU make 4.0 -- no maintainer mode, power supply plugged, build on SSD:
real 0m16.607s
4.0, no maintainer mode, irst run, caching dependencies, power supply plugged, build on SSD:
real 0m22.530s
4.0, no maintainer mode, econd run, using cache, power supply plugged, build on SSD:
real 0m11.070s
4.0, no maintainer mode, second run, using cache, power supply plugged, build on tmpfs:
real 0m11.155s
More information about the LibreOffice
mailing list