From: Lynn Winebarger <owinebar@gmail.com>
To: Gregory Heytings <gregory@heytings.org>
Cc: Yuan Fu <casouri@gmail.com>, emacs-devel <emacs-devel@gnu.org>
Subject: Re: Unboxed package manager
Date: Tue, 21 Mar 2023 06:36:23 -0400 [thread overview]
Message-ID: <CAM=F=bDR1u2rWGGrG72bJFdV0MvpVgWzxY5puc+q8G2xCcvKUw@mail.gmail.com> (raw)
In-Reply-To: <CAM=F=bAT51AoBu3kN+=gD7-kp8Lt-6fvB8yFCjMJ76EEjFVrqQ@mail.gmail.com>
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
next prev parent reply other threads:[~2023-03-21 10:36 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-20 1:18 Unboxed package manager Lynn Winebarger
2023-03-20 6:30 ` Yuan Fu
2023-03-20 8:55 ` Lynn Winebarger
2023-03-20 9:09 ` Lynn Winebarger
2023-03-20 15:25 ` Philip Kaludercic
2023-03-20 16:12 ` Lynn Winebarger
2023-03-20 16:53 ` Philip Kaludercic
2023-03-20 18:11 ` Jonas Bernoulli
2023-03-21 1:40 ` Lynn Winebarger
2023-03-22 11:17 ` Jonas Bernoulli
2023-03-22 14:31 ` Lynn Winebarger
2023-03-22 23:39 ` Lynn Winebarger
2023-03-21 19:06 ` Augusto Stoffel
2023-03-21 19:10 ` Philip Kaludercic
2023-03-21 19:57 ` Augusto Stoffel
2023-03-21 20:06 ` Philip Kaludercic
2023-03-21 0:23 ` Gregory Heytings
2023-03-21 0:25 ` Gregory Heytings
2023-03-21 1:55 ` Lynn Winebarger
2023-03-21 10:36 ` Lynn Winebarger [this message]
2023-03-21 10:52 ` Gregory Heytings
2023-03-21 13:23 ` Eli Zaretskii
2023-03-21 13:33 ` Gregory Heytings
2023-03-21 14:13 ` Eli Zaretskii
2023-03-21 14:20 ` Gregory Heytings
2023-03-21 17:29 ` Eli Zaretskii
2023-03-22 0:48 ` Lynn Winebarger
2023-03-22 14:42 ` Eli Zaretskii
2023-03-22 22:22 ` Lynn Winebarger
2023-03-23 6:46 ` Eli Zaretskii
2023-03-23 13:30 ` Lynn Winebarger
2023-03-24 17:54 ` chad
2023-03-26 1:51 ` Lynn Winebarger
2023-03-23 1:44 ` David Masterson
2023-03-23 7:02 ` Eli Zaretskii
2023-03-22 7:29 ` tomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAM=F=bDR1u2rWGGrG72bJFdV0MvpVgWzxY5puc+q8G2xCcvKUw@mail.gmail.com' \
--to=owinebar@gmail.com \
--cc=casouri@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=gregory@heytings.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).