Re: Bug#1023870: dpkg: Problems in buildds due to slow compression
On Sat, Nov 12, 2022 at 11:42:20PM +0100, Aurelien Jarno wrote:
>...
> On 2022-11-12 23:04, Adrian Bunk wrote:
>...
> > Sebastian, was there any real-world problem motivating your commit,
> > or did it just sound more correct?
> >
> > With default settings there should be < 100 MB/core RAM usage,
> > and even with "xz -9"[1] RAM usage should be < 700 MB/core.
>
> I think the use case there, is for the desktop. It's preferable to use 2
> threads only on a 4 core processor than sending Firefox to the swap.
> That said that heuristics is not necessary the best for the build
> daemon.
>...
On a desktop that managed to successfully build a package large enough
that multithreaded compression is even possible, why does it matter
whether compression needs 200 MB or 400 MB of RAM?
You can create a huge data package where the build just copies the data
from the source package and then compresses with "xz -9", but the common
case for big packages is C++ code where even in a single-threaded build
g++ might need > 2 GB and then compressed with the default "xz -6".
IOW, if building on a desktop that is so RAM-starved that this code
would matter, I would expect that Firefox was already sent to swap
during compilation.
> Regards
> Aurelien
cu
Adrian
Reply to: