On Sat 01 Jul 2017 15:33, l...@gnu.org (Ludovic Courtès) writes: > Leo Famulari <l...@famulari.name> skribis: > >> My understanding is that Guile 2.2 traded slower compilation for faster >> execution of compiled programs. Hopefully the performance of the >> compiler will be improved in later updates to Guile. > > Yes, that’s a good summary. > > Most of the code we compile is package definitions that don’t benefit > from all the fancy optimizations, so build-aux/build-self.scm (run by > ‘guix pull’) turns those off. > > Unfortunately even with this change compilation is slower than with > Guile 2.0, and IMO unacceptably slow for ‘guix pull’ (it takes only a > few minutes at most on my laptop, but that’s a lot if we compare to > ‘apt-get update’.) > > Andy, do you have other approaches in mind that we could explore to > improve on this? Evaluating all of gnu/packages instead of compiling it > AOT would probably be bad for memory and CPU consumption.
I agree that this is a correct summary. I think it's possible that even with improvements that 2.2 would remain slower than 2.0 to compile, but the current situation is clearly not good and needs improvement. I think we need to revisit that synthetic python.scm test you had (can't find it atm), see where the compiler is spending time, and focus effort there. As far as what Guix can do -- there I don't know :/ Nothing immediate comes to mind. I would like to help here but can't promise much over the summertime... Andy
