Re: Unboxed package manager

[Lynn Winebarger]

On Mon, Mar 20, 2023 at 9:55 PM Lynn Winebarger <owinebar@gmail.com> wrote:
> On Mon, Mar 20, 2023 at 8:25 PM Gregory Heytings <gregory@heytings.org> wrote:
> > >> my recollection is that installing ~1200 packages on those systems and
> > >> "loading the world" took something like 5 minutes
> > >
> > > I'm not sure I understand what you mean here.  Do you mean that
> > > byte-compiling and loading ~1200 packages takes about 5 minutes (which
> > > would not be a problem per se AFAIU)?  Or that loading ~1200 already
> > > byte-compiled packages takes about 5 minutes?  I took the file you
> > > posted in bug#61004, modified it a bit to make it work with emacs -Q
> > > (without external packages), and on my computer emacs -Q -l loadall.el
> > > takes ~4.5 seconds.
>
> You're right, my wording is very confusing.  The installation phase
> took much, much longer than 5 minutes.  Loading the world, after
> everything was byte-compiled, took about 5 minutes.  The 1200 packages
> is just to give the number of directories prepended to the standard
> load-path (it was more work to get those packages on those sandboxed
> systems, hence "only" 1200, not the 2400+ I currently have on my
> personal machine).  The number of libraries being loaded was closer to
> 4000, if I am recalling correctly (big if - this is ~9 months ago).
> That was on fairly nice server hardware with SSDs, lots of RAM, and 24
> cores.
>
> I'm pretty sure the profiling report I filed for #61004 was generated
> on a 2017-vintage laptop with a physically spinning disk for storage.
> I don't think it would run emacs -Q -l loadall.el in 4.5 seconds on
> that laptop, but with "-Q" you're taking out the main drag on the
> startup time - having to search 1000-2000+ directories before getting
> to the system directories where all the libraries in loadall.el will
> actually be found.

Thanks for checking this out, BTW.

You could construct a test without external packages by just
generating N directories, prepending them to the load path, then doing
the same loadall to see if the degradation is purely due to the size
of the load path.

Lynn