Andy Wingo transcribed 1.5K bytes:
> On Sat 01 Jul 2017 15:33, ludo@gnu.org (Ludovic Courtès) writes:
> 
> > Leo Famulari <leo@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