Hi Alex, On Wed, Jun 02, 2021 at 05:07:16PM +0200, Alex Muntada wrote: > This reminded me of my using of ccache and eatmydata in sbuild. > They may not be relevant for the context of mdbp depending on > the resources available for building, indeed. > > I'm pretty fond of them because they speed up a lot some heavy > builds on my laptop, therefore I'd appreciate to have some speed > toggles in any service where I want to send those builds to.
TL;DR: Don't add speedup flags, make it fast by default. I don't think speedups are relevant for any of the prospective users. ccache either needs a small set of packages or a huge cache directory to perform well. For many use cases (rebootstrap in particular), the toolchain changes frequently, so the cache would have to be invalidated very often. Most mdbp users would work with at least hundreds of packages. As for eatmydata, I don't think that adding this as toggle is useful. After all, we don't want eatmydata to have any influence on the build. So a mdbp backend can just unconditionally enable it if it makes sense without concerning a prospective user of the API. A very reliably alternative to eatmydata is building on tmpfs with a huge swap partition. It also performs significantly better than eatmydata in my experience as it fully eliminates the need to write to disk a lot of the time. When you use pbuilder's "extract tarball" approach or a type=file schroot with sbuild on a tmpfs (optionally speeding things up by using zstd as compressor), the chroot setup can feel quite instantaneous. Ultimately, speedups should just become the default for the benefit of everyone rather than opt-in. If I remember correctly, pbuilder now defaults to disable man database generation via debconf, which also provides a useful speedup. Helmut
