From: Lynn Winebarger <owinebar@gmail.com>
To: John Yates <john@yates-sheets.org>
Cc: Emacs developers <emacs-devel@gnu.org>, Andrea Corallo <akrl@sdf.org>
Subject: Re: emacs empty startup time increased from v 27.1 to 29.0 by factor 3?
Date: Sat, 28 Jan 2023 04:00:53 -0500 [thread overview]
Message-ID: <CAM=F=bA8znBjHQU3Hou+rGf9w3hOZHoUXKtX-VhWQx71YQ1QXg@mail.gmail.com> (raw)
In-Reply-To: <CAJnXXoiiPc-PBE0B194922H1GW=6-ONd5xi7Jx0eVCAcsvm8Sw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2621 bytes --]
Hi, John,
The closest thing in Emacs to what you describe is dumping, which currently
isn't supported for native compilation, unless something has changed that
I'm not aware of.
Last summer I did an experiment and modified 28.1 to support dumping native
compilation. I had a startup that was loading all libraries included with
emacs and approximately an additional 1000 packages installed in site-lisp
(lots of manual modifications to make that happen).
Loading those packages at startup as regular packages, after ensuring all
were compiled ahead of time, increased startup time to 15 minutes or more.
The dumped version only took 5 seconds or so.
I discarded that experiment, but have done a similar site-lisp installation
with maybe half of those additional packages. The dump produced by
"dump-emacs-portable" starts almost instantly. Even without dumping,
startup time is only 30 seconds or so. For that matter, it takes 12
minutes to dump the byte-compiled function, where dumping the natively
compiled version would take over 30 minutes. It's not a completely fair
comparison since (if memory serves) the natively compiled version loaded
4000-5000 files where this version is only loading ~2200 libraries.
Loading natively compiled libraries does do some additional checking to
compare source file to the compiled library by checksum. Maybe that's part
of the 3x you're seeing?
Lynn
On Fri, Jan 27, 2023, 12:22 PM John Yates <john@yates-sheets.org> wrote:
> Reposting to emacs-devel at Eli's behest.
>
> Re my suggested parallel, Eli asked:
>
> > How many hundreds? Emacs 29 loads almost 300 *.eln files at startup.
>
> I have never needed to answer that question.
>
> I work on the code generation middle-end. When I modify one of its
> fundamental headers over 350 modules get rebuilt. (That number
> reflects poor dependency management, which is being addressed.)
> There are probably just as many modules unrelated to code generation
> (e.g. UI, graphics, etc).
>
> /john
> ---------- Forwarded message ---------
> From: John Yates <john@yates-sheets.org>
> Date: Thu, Jan 26, 2023 at 8:16 PM
> Subject: Re: emacs empty startup time increased from v 27.1 to 29.0 by
> factor 3?
> To: <help-gnu-emacs@gnu.org>
>
>
> I work on a product whose structure involves literally hundreds of
> DLLs / SOs. We tolerate slow start-up in-house because it optimizes
> the compile / edit / debug cycle.
>
> Packaging the final product involves an extra step to collapse our
> hundreds of images into just a handful via a secondary link step.
> I wonder if there is anything analogous that Emacs could do.
>
>
[-- Attachment #2: Type: text/html, Size: 4457 bytes --]
next prev parent reply other threads:[~2023-01-28 9:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <873581tkc0.fsf@no.workgroup>
[not found] ` <83pmb5i90e.fsf@gnu.org>
[not found] ` <87a624zw0e.fsf@no.workgroup>
[not found] ` <CAJnXXohhSOxg82bw3aZn5tjUBmAOkStaNQFjUrV5FhHFpRO34g@mail.gmail.com>
2023-01-27 17:20 ` Fwd: emacs empty startup time increased from v 27.1 to 29.0 by factor 3? John Yates
2023-01-28 9:00 ` Lynn Winebarger [this message]
2023-01-28 12:22 ` Eli Zaretskii
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=bA8znBjHQU3Hou+rGf9w3hOZHoUXKtX-VhWQx71YQ1QXg@mail.gmail.com' \
--to=owinebar@gmail.com \
--cc=akrl@sdf.org \
--cc=emacs-devel@gnu.org \
--cc=john@yates-sheets.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).