Re: Maybe a way to get a few more developpers to work on Guix ?

[Csepp]

Vagrant Cascadian <vagrant@debian.org> writes:

> [[PGP Signed Part:Undecided]]
> On 2023-06-24, Nicolas Graves via "Development of GNU Guix and the GNU System 
> distribution." wrote:
>> On 2023-06-24 13:08, Csepp wrote:
>>> Nicolas Graves via "Development of GNU Guix and the GNU System 
>>> distribution." <guix-devel@gnu.org> writes:
>>> IMHO LLMs for Guix are so damn not worth the effort.  It will not fix
>>> any of the actual issues with Guix, like the huge performance gap
>>> between it and traditional package managers.
>>
>> I've also opened another discussion on the subject on guix-devel
>> recently. Do you have any benchmark material to back this up?
>
> Well, I just ran "apt update" on Debian, and it took approximately 7
> seconds, which was mostly spent downloading moderately sized files from
> Debian mirrors (~1MB).
>
> A corresponding "guix pull" took 299 seconds, downloading at least 8MB
> (from a quick eyeball calculation as guix does not summarize the results
> for me), and compiling all the various guix-*.drv that make up guix
> pull. The vast majority of the time was spent compiling
> derivations. This was also using a local copy of guix.git, so having to
> update guix.git over the network would take even longer... (and it did
> even spend a fair amount of time copying from the local guix.git on a
> fast NVMe device)
>
> Obviously, guix pull is doing a lot more, but it is ... doing a lot
> more!
>
> "apt install hello" (~2.3 seconds) and "guix install hello" (~1.5
> seconds) were actually in a similar ballpark, which honestly surprised
> me. Guix is much faster with "guix remove hello" ... although arguably
> "guix remove hello && guix gc --delete $(guix build hello)" would be a
> more similar operation, and although I did not time it, it was
> reasonably fast, too.
>
> So, presuming substitutes are available, the main slowness with guix
> seems to be guix pull?

NVMe (or even an SSD) helps a lot.  And I suspect your system also has a
good amount of RAM for IO caching and at least 4 modern 64 bit cores.
Try running guix pull on a 32 bit machine with 1 GB of RAM and an HDD
with LUKS for storage (and a lot of swap), you'll see a waaaay wider
performance gap.
Even simple operations like guix edit take much longer than they should.
Yes, Guix does more, but a lot of what it does could be sped up.