On Fri, 10 Feb 2023 at 17:05, Roberto A. Foglietta < roberto.foglietta@gmail.com> wrote: > On Wed, 25 Jan 2023 at 05:48, Roberto A. Foglietta < > roberto.foglietta@gmail.com> wrote: > >> On Thu, 19 Jan 2023 at 19:08, Roberto A. Foglietta > > SSTATE CACHE REWORK + APT CACHE MOUNT BIND ========================================== Debug code is still in place but the APT cache and lists are offered by binding. Binding is the favourite way to offer APT cache and repositories lists but not with sbuild because the lock contention is not supported with binding. It is using soft links but in an improved declination. devel4 (public) + npriv12 (private) ------------------------------------ fresh cache ------------ complete -------------- 32417 Mb (max) | 27740 Mb (max) 23294 Mb (rest) | 18657 Mb (rest) 4283 Mb (deb) | 4283 Mb (deb) 8989 Mb (wic) | 8987 Mb (wic) <-- cache! 4398 Mb (cache) | 4398 Mb (cache) time: 12m01s | time: 2m30s [*] 4.81x ------------ original --------------------- time: 21m17s | time: 8m28s 1.77x 3.39x devel4 (public) + npriv12 (private) ------------------------------------ fresh cache ------------ basic-os -------------- 3946 Mb (max) | 3176 Mb (max) 2976 Mb (rest) | 2278 Mb (rest) 4283 Mb (deb) | 4283 Mb (deb) 803 Mb (wic) | 802 Mb (wic) <-- cache! 520 Mb (cache) | 520 Mb (cache) time: 3m05s | time: 20s 9.25x ------------ original --------------------- time: 7m58s | time: 2m17s 2.58x 6.85x These numbers show that Ilbers' ISAR improved a lot during the time original, fresh 21m17s complete, next, devel3, fresh 16m49s 1.27x complete, next.plus, devel3, fresh 15m49s 1.35x complete, npriv.12, devel4, fresh 12m01s 1.77x original, cache 8m28s complete, next, devel3, cache 5m15s 1.61x complete, next.plus, devel3, cache 3m18s 2.57x complete, npriv.12, devel4, cache 2m30s 3.39x For completeness: next.plus is the next with all the patches applied from the mailing list, all those patches that are supposed to improve the building speed. Considering that the nvidia-modules compilation takes 2m4s and producing the wic image takes 2m8s in the complete build but these activities are not part of the optimisation, we have these numbers: original, fresh 17m05s complete, next, devel3, fresh 12m37s 1.35x complete, next.plus, devel3, fresh 11m37s 1.48x complete, npriv.12, devel4, fresh 7m49s 2.19x original, cache 6m20s complete, next, devel3, cache 3m07s 2.03x complete, next.plus, devel3, cache 1m10s 5.43x complete, npriv.12, devel4, cache 0m22s 17.27x The last number 22s is coherent with the basic-os cached building time. [*] after 2m the complete fresh build, SSD needs to relax internally which is fully acceptable in a real-case scenario. The original time values are still correct because at the time they have been taken there was not a script that immediately after the complete build was started the cached building.