You are not logged in.
For several years I am asking myself why Pacman seems to be significant faster than other major packing managers like whatever Debian/Ubuntu/Opensuse are using.
Please note, I am using Archlinux since 2009 as my main driver and due to this short testing phase I am not very good at Archlinux (very good at pacman -Syu, though) or Linux or actually anything except eating Milk with cookies. I tried to do research via a modern internet search machine, but the answers are way too complicated and I am not an engineer. "Dependencies"?!, I am not very good with taxes.
Would you please explain in simple word using train and football analogues (mentioning Lionel Messi helps understanding) why Pacman seems to be significant faster than other major packing managers?
Thank you.
Offline
My take is that it does less? The mirrors are good maybe? Maybe a combination of several factors?
Bleeding edge may be the thing, don’t update for a month and you get some more “slow” speed, tho I once waited a month and it got quite quick but my env is tiny...
Or eschwartz magic is the culprit, yeah, blame the wizard. That works.
Offline
I don't see much difference between pacman and apt-get or yum anymore.
Pacman once was fast, because it was lightweight and simple.
It still somehow is, but since the introduction of hooks, I don't see any significant performance increase any more compared to other package managers, especially on large updates.
Don't get me wrong here: I love ALPM hooks and find them very useful. But everything has its price...
Last edited by schard (2021-02-15 15:02:22)
Offline
why Pacman seems to be significant faster than other major packing managers?
In Arch Linux, partial upgrades are unsupported and only a single version of each shared library [is] in the official repositories, in contrast to other (non-rolling-release) distros.
This simple rule avoids (for the most part) the intractable issue that dependency hell is NP-complete. Maintaining metadata for complex version resolution has the effect that Linux package managers are slow (2019).
--
saint_abroad
Offline
My take is that it does less?
^ This.
APT has to deal with multiple releases, development branches and pinning, none of which apply to pacman; aptitude(8) even has a curses interface and uses an "advanced" dependency resolution algorithm which makes it even slower.
By contrast, Alpine's package manager (apk) does even less than pacman (it has simple triggers but no hooks, APKBUILDs don't offer optdepends and use POSIX sh instead of bash) and as a result it's even faster.
Online
pacman doesn't run fsync() all the time, unlike apt-get. Disable it (e.g. through "eatmydata") and both are comparably fast.
Then there's dnf... which seems purposely designed to make package installations as long as installing an entire operating system. For that you get more-or-less useful features like transactions and rollbacks.
APKBUILDs don't offer optdepends and use POSIX sh instead of bash) and as a result it's even faster.
pacman doesn't do a whole lot with optdepends (apart from displaying them) so I doubt it plays a significant role.
Last edited by Alad (2021-02-15 18:46:00)
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Honest Alad's Package Emporium—Now with added bugs! (Grand reopening: December 1st 2018)
Offline
pacman doesn't run fsync() all the time, unlike apt-get. Disable it (e.g. through "eatmydata") and both are comparably fast.
I take it you haven't used aptitude(8) much then? It's almost as slow as OpenBSD's package manager and that's written in perl.
APKBUILDs don't offer optdepends and use POSIX sh instead of bash) and as a result it's even faster.
pacman doesn't do a whole lot with optdepends (apart from displaying them) so I doubt it plays a significant role.
Probably not, no. I was just offering some examples of the reduced functionality offered by Alpine's package manager, which is the fastest around.
Anyway, this article may be of interest to the OP: https://michael.stapelberg.ch/posts/201 … -are-slow/
Online
It still somehow is, but since the introduction of hooks, I don't see any significant performance increase any more compared to other package managers, especially on large updates.
Strange... since hooks actually reduce the repetitive install scripts and make installing faster. e.g. every package installing a .desktop or .info file does not need to update the relevant database - it now happens once at the end.
But there are a lot more things that trigger mkinicpio these days...
Offline
Or eschwartz magic is the culprit, yeah, blame the wizard. That works.
Has Eli submitted patches to pacman? makepkg yes, but pacman...
Offline
Train and football analogies were specifically requested.
Packages: footballs
Mirrors: trains full of footballs
Pacman: Lionel Messi
Installing packages: Lionel Messi kicking footballs into the goal.
Faster mirrors -> faster trains, footballs get to Messi's feet faster (not sure that mirror speed matters, but it was mentioned in the thread so analogy, plus I don't see where else I'm going to fit in a train analogy here)
Hooks: Messi poses for the cameras once before kicking in the goals and once after, so faster than posing between each kick.
Single version of each package: all of the footballs are the same color. Messi doesn't need to pay attention to the color of the balls and carefully choose which ones he kicks in
No constant fsyncs: Messi doesn't have to wait for each goal to go in before kicking the next ball.
Cognitive bias: You're a Messi fan so you're biased and and won't admit that other players are just as good and some are even better.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline
Has Eli submitted patches to pacman? makepkg yes, but pacman...
It's not my forte, but I actually have!
There's the one-liner libarchive flag to enable xattrs I just contributed... https://git.archlinux.org/pacman.git/co … 7a105fe42b
My first ever patch to libalpm was fixing gcc8 warnings: https://git.archlinux.org/pacman.git/co … aeb65d9b7b
And I've even touched
vercmp:
https://git.archlinux.org/pacman.git/co … d3e6d60932
https://git.archlinux.org/pacman.git/co … 99f54b34fc
pacman:
https://git.archlinux.org/pacman.git/co … e5b6ea00c5
https://git.archlinux.org/pacman.git/co … 519f022386
pacman-conf:
https://git.archlinux.org/pacman.git/co … 1e5a56ba7f
https://git.archlinux.org/pacman.git/co … 6ed1d42a0a
Admittedly, I hardly ever touch pacman's code. But I do it often enough to pretend from a distance that I actually know C somewhat...
Last edited by eschwartz (2021-02-16 01:35:41)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Cognitive bias: Your a Messi fan so you're biased and and won't admit that other players are just as good and some are even better.
I think we are all of the opinion that APK is super fast, and DNF is super slow.
I don't know round ball footballers to compare them too...
Offline
mento wrote:why Pacman seems to be significant faster than other major packing managers?
In Arch Linux, partial upgrades are unsupported and only a single version of each shared library [is] in the official repositories, in contrast to other (non-rolling-release) distros.
This simple rule avoids (for the most part) the intractable issue that dependency hell is NP-complete. Maintaining metadata for complex version resolution has the effect that Linux package managers are slow (2019).
Oh incidentally...
Note that some packagers today are quite anxious to modify packages, wherever possible, to depend on versioned provides, e.g. "libglib-2.0.so=0-64" rather than "glib2".
The goal is to have pacman refuse to update iff you try to do a partial update, there is zero intention to support complex version resolution in order to select the right package to install. Even so, I wonder what effect this will have on the pacman solver.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Even so, I wonder what effect this will have on the pacman solver.
Near zero surprisingly... At least according to the benchmarks I have seen. That still surprises me a lot.
Offline
Alad wrote:pacman doesn't run fsync() all the time, unlike apt-get. Disable it (e.g. through "eatmydata") and both are comparably fast.
I take it you haven't used aptitude(8) much then? It's almost as slow as OpenBSD's package manager and that's written in perl.
I stopped using it after it turned out it is not interchangeable with apt-get and broke my Debian sid system
OpenBSD's package manager is a whole different league. When I used it took three hours to install libreoffice and it was a binary package...
Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby
Honest Alad's Package Emporium—Now with added bugs! (Grand reopening: December 1st 2018)
Offline
OpenBSD's package manager is a whole different league. When I used it took three hours to install libreoffice and it was a binary package...
You have to use the "--disable-gentoo-emulation" flag to avoid that.
My Arch Linux Stuff • Forum Etiquette • Community Ethos - Arch is not for everyone
Offline