| Message ID | 20200911144049.14632-1-ludo@gnu.org |
|---|---|
| Headers | show |
Hey Ludo, >> Specifically, it implements option #4 (spawning ‘guix authenticate’ >> once for the whole session, instead of spawning it every time a >> store item needs to be signed or authenticated), achieving a ~15x >> speedup, which is not bad. :-) Woo, congrats! > Below is the new Gantt chart for: > > perf timechart record guix archive --export -r $(guix build coreutils -d) -v3 >/tmp/dump > > Most of the work happens in ‘guix authenticate’. I never used the "timechart" sub-command but it sounds really nice. Regarding the option you chose, I think it's the more appropriate right now. It's very delicate to dedicate time and effort to tweak guix-daemon and how we use it, having in mind that we'd like to get rid of it. However, the potential short term gains can be so huge, that for now it's the best thing to do. I should just do like you, and dive into it to see what can be done for contention and locking when using 'build-paths' RPC via Cuirass. In the meantime, a short review that I hope to complete next week. Thanks for your efforts, Mathieu
Hi! Mathieu Othacehe <othacehe@gnu.org> skribis: >>> Specifically, it implements option #4 (spawning ‘guix authenticate’ >>> once for the whole session, instead of spawning it every time a >>> store item needs to be signed or authenticated), achieving a ~15x >>> speedup, which is not bad. :-) > > Woo, congrats! To be clear, it’s 15x on the pathological case where we send only small store items; the difference is obviously less significant if few store items are exported or if the store items are large. Now, I expect it to make a noticeable difference on the typical build farm workload. >> Below is the new Gantt chart for: >> >> perf timechart record guix archive --export -r $(guix build coreutils -d) -v3 >/tmp/dump >> >> Most of the work happens in ‘guix authenticate’. > > I never used the "timechart" sub-command but it sounds really > nice. Regarding the option you chose, I think it's the more appropriate > right now. It's very delicate to dedicate time and effort to tweak > guix-daemon and how we use it, having in mind that we'd like to get rid > of it. Yeah. > However, the potential short term gains can be so huge, that for now > it's the best thing to do. I should just do like you, and dive into it > to see what can be done for contention and locking when using > 'build-paths' RPC via Cuirass. Yup, makes sense! > In the meantime, a short review that I hope to complete next week. Thanks for your feedback! Ludo’.