I've never used SDDs, so I've been experiencing this since I installed Guix (~5 years ago). And yes, building the profile seems to be the more resource intensive operation. I usually can't do anything else while that happens because the computer becomes unresponsive.
Running the same command Maxim mentioned took the following time in my case:
I haven't run this command because I don't know what it does (how will it affect my profile?), but if you think the results from this command would be more useful than what I posted to issue #44053, please let me know and I'll run it.
> > > Clever workaround! What are now the performances on previous examples
> > > (same profiles and same packages)?
> > In my case there seem to be no improvement (using Guix 5e7cf66fb35780f930ad0bc5fe21ac330df4411d).
> Please note that the change above addresses only one specific source of
> slowness, the ‘xdg-mime-database’ hook, and only in specific cases.
> It’s good to look at the overall timing of ‘guix install’, because
> that’s what matters in the end, but as we work on optimizing it, we have
> to look at specific aspects of it.
> > $ time guix package -i perl --max-jobs=1
Yeah, sorry I was more focused on the general issue (#44053), but I understand.
Toggle quote (17 lines)
> > injertando 12 paquetes en /gnu/store/anknpdyhmfirw3rz2k9zm9kiyak8yy1s-cups-filters-1.27.4.drv ...
> > construyendo la base de datos MIME XDG...
> > injertando 3 paquetes en /gnu/store/xgny7xbl635g8na8x03x4cdr7abiphiw-cups-2.3.3.drv ...
> > injertando 20 paquetes en /gnu/store/yhjl68x7kcjbv40v823x4hl8rvv8l50b-gtk+-2.24.32.drv ...
> > injertando 21 paquetes en /gnu/store/kq37fnw8335f1hqc3j4hhqqcdnhl371p-gtk+-3.24.20.drv ...
> > creando la caché de temas de iconos de GTK+...
> > construyendo los ficheros de caché para los métodos de entrada de GTK+...
> > construyendo perfil con 86 paquetes...
> > real 8m38,121s
> > user 0m2,742s
> > sys 0m0,338s
> Here it’s likely that grafting is what’s taking the most time on a
> spinning disk.
It does take some time, but since I can see the output change from grafting to grafting, I at least can tell guix is doing something, so I just let it be.
Compared to grafting, the last step "construyendo perfil con X paquetes..." ("building profile with X packages..."), just stays there without change for several minutes, so it actually seems slower to me. Initially, I thought that guix had frozen.
Also, even though, the "building profile" step has a throbber (| / - \) to indicate that something is being done, it frequently stops in one of the frames of the sequence and stays there until the end.
Toggle quote (7 lines)
> We should hack (guix status) so it can optionally prefix each event with
> a timestamp.
> As far as ‘xdg-mime-database’ is concerned, it should be down to 0s,
> unless your profile contains one of the packages I cited (libreoffice,
(name . Luis Felipe)(address . email@example.com)
Luis Felipe <firstname.lastname@example.org> skribis:
Toggle quote (4 lines)
> Compared to grafting, the last step "construyendo perfil con X paquetes..." ("building profile with X packages..."), just stays there without change for several minutes, so it actually seems slower to me. Initially, I thought that guix had frozen.
> Also, even though, the "building profile" step has a throbber (| / - \) to indicate that something is being done, it frequently stops in one of the frames of the sequence and stays there until the end.
Interesting, so we should profile that step and see what can be done. I
suspect it’s I/O-bound, but maybe we can at least improve feedback.