Le mercredi 1 janvier 2025, 20:13:35 UTC+1 Ahmad Khalifa a écrit :
> On 01/01/2025 18:27, Aurélien COUDERC wrote:
> > Here’s a quick « benchmark » in a sid Plasma desktop qemu VM where I had a
> > snapshot of up-to-date sid from Nov 24th, upgrading to today’s sid :
> >
> > Summary:
> > Upgrading: 658, Installing: 304, Removing: 58, Not Upgrading: 2
> > Download size: 0 B / 1 032 MB
> > Space needed: 573 MB / 9 051 MB available
> >
> > # time apt -y full-upgrade
> >
> > real 9m49,143s
> > user 2m16,581s
> > sys 1m17,361s
> >
> > # time eatmydata apt -y full-upgrade
> >
> > real 3m25,268s
> > user 2m26,820s
> > sys 1m16,784s
> >
> > That’s close to a *3 times faster* wall clock time when run with eatmydata.
>
> The second upgrade hasn't been written back at all. For up to 30
> seconds, if your machine loses power and for example grub.{cfg,efi} or
> shim.efi was updated, you can't boot at all. Not to mention Kernel
> panics still happen.
Yes but no. :)
It’s true that I should have included a final sync in the measurement but in
practice it makes no difference because writing however many 100s of MB in a
single sync is almost instantaneous.
Here’s a new run with a final sync :
# time eatmydata apt -y full-upgrade ; time sync
real 3m25,116s
user 2m26,947s
sys 1m17,962s
real 0m0,109s
user 0m0,002s
sys 0m0,000s
> Surely, we can all agree dpkg should at least do a single 'sync' at the
> end? Perhaps this would be a more realistic comparison?
> # time (eatmydata apt -y full-upgrade; sync)
Yes I never said the contrary, the kind of guarantees that dpkg and/or apt are
providing are highly valuable.
It would be better if it was not coming at such a high cost.
Happy hacking,
--
Aurélien
