Andy Wingo transcribed 1.5K bytes: > 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 > >
What about the sledgehammer approach: Would it help if we just split the incredible long modules into smaller modules like python-web, python-library, etc? -- ng0 GnuPG: A88C8ADD129828D7EAC02E52E22F9BBFEE348588 GnuPG: https://n0is.noblogs.org/my-keys https://www.infotropique.org https://krosos.org
signature.asc
Description: PGP signature
