unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Daniel Colascione" <dancol@dancol.org>
To: "Paul Eggert" <eggert@cs.ucla.edu>
Cc: Eli Zaretskii <eliz@gnu.org>,
	Daniel Colascione <dancol@dancol.org>,
	schwab@linux-m68k.org, rpluim@gmail.com, emacs-devel@gnu.org
Subject: Re: Finding the dump
Date: Mon, 28 Jan 2019 11:46:19 -0800	[thread overview]
Message-ID: <f0549e9574b762d937ed42c661dd61c8.squirrel@dancol.org> (raw)
In-Reply-To: <3fe7b1fc-628e-7a2e-c3a9-c80db9a14e39@cs.ucla.edu>

> On 1/28/19 8:02 AM, Daniel Colascione wrote:
>> The overhead of opening a file in libexec is negligible.
>
> It's not just opening the file; it's reading the file and eagerly
> converting its data to internal format.

Data conversion is slow, which is why pdumper doesn't do it. The dump is a
memory image, not an elc file. We do need to relocate the dump in order to
adjust it for ASLR, but any dumper approach needs to do that, or disable
ASLR.

I experimented with a non-relocatable, relocation-less mode for pdumper
--- just mark Emacs as non-PIC and embed the dump in the emacs data
segment, so it's located at a constant address in memory on each run ---
but it turns out that relocation is so fast, only 1-2ms, that it's really
not worth the trouble. And from a security POV, we shouldn't be
encouraging people to disable ASLR.

I'm not sure what your proposal is, exactly, or how it would differ from
this non-PIC pdumper mode.

> Not everybody cares as much about startup latency as I do, and I can
> understand it if the issue does not seem that important to others. But
> on my platform, Emacs master's startup time is more than twice as long
> than (say) Python 3's, and I'd like to see Emacs catching up rather than
> falling further behind.

One option is to do pdumper relocations on-demand, in a SIGSEGV handler. I
actually implemented this approach, and it works fine, but because we have
a dumb stop-the-world non-generational GC, we ended up paging in most of
the dump on the first GC anyway, so doing relocations on demand doesn't
actually help. If we had a generational GC, we could avoid paging in most
of the dump, speeding both startup and steady-state performance.

But look at it from a different POV: we can make emacs -Q faster, but the
performance of emacs -Q doesn't matter for most users. Most user-visible
startup latency comes from user customization. The single biggest
improvement we can make to observed startup time for typical users is to
use pdumper to automatically checkpoint Emacs after user customization
and, on subsequent startups, skip all the ~/.emacs work. I explicitly
designed pdumper to make this use case possible. This change, along with
automatic .elc maintenance, will do more for real-world Emacs performance
than GC tweaks or incremental improvements to pdumper load performance.






  reply	other threads:[~2019-01-28 19:46 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-23 13:15 Finding the dump Stefan Monnier
2019-01-23 13:46 ` Robert Pluim
2019-01-23 15:13   ` Stefan Monnier
2019-01-23 13:55 ` Andreas Schwab
2019-01-23 15:17   ` Stefan Monnier
2019-01-23 15:37     ` Andreas Schwab
2019-01-23 15:44 ` Andreas Schwab
2019-01-23 16:07   ` Stefan Monnier
2019-01-23 15:50 ` Eli Zaretskii
2019-01-23 16:02   ` Stefan Monnier
2019-01-23 16:04   ` Paul Eggert
2019-01-23 16:38   ` Robert Pluim
2019-01-23 17:24     ` Eli Zaretskii
2019-01-26 12:17       ` Eli Zaretskii
2019-01-26 15:03         ` Andreas Schwab
2019-01-26 15:12           ` Eli Zaretskii
2019-01-26 15:44             ` Andreas Schwab
2019-01-26 17:02               ` Eli Zaretskii
2019-01-26 20:44                 ` Andreas Schwab
2019-01-27 15:20                   ` Eli Zaretskii
2019-01-27 15:46                     ` Andreas Schwab
2019-01-27 15:59                       ` Eli Zaretskii
2019-01-27 16:37                         ` Andreas Schwab
2019-01-27 16:56                           ` Eli Zaretskii
2019-01-27 17:00                             ` Andreas Schwab
2019-01-27 18:26                           ` Daniel Colascione
2019-01-27 18:46                             ` Andreas Schwab
2019-01-27 18:58                               ` Stefan Monnier
2019-01-27 19:27                               ` Daniel Colascione
2019-01-27 19:42                                 ` Stefan Monnier
2019-01-28  1:06                                   ` Daniel Colascione
2019-01-27 20:12                                 ` Andreas Schwab
2019-01-27 21:25                                   ` Daniel Colascione
2019-01-27 21:37                                     ` Andreas Schwab
2019-01-27 23:47                                       ` Paul Eggert
2019-01-28  0:32                                         ` Daniel Colascione
2019-01-28  1:21                                           ` Paul Eggert
2019-01-28  1:29                                             ` Daniel Colascione
2019-01-28 19:03                                             ` Richard Stallman
2019-01-28 19:23                                               ` Paul Eggert
2019-01-28 23:09                                                 ` Stefan Monnier
2019-01-29  8:50                                                 ` Richard Stallman
2019-01-31  2:21                                                   ` Paul Eggert
2019-02-01  0:23                                                     ` Richard Stallman
2019-02-01  2:09                                                       ` Paul Eggert
2019-02-02  3:25                                                         ` Richard Stallman
2019-02-02  7:23                                                           ` Eli Zaretskii
2019-02-03  4:36                                                             ` Richard Stallman
2019-02-01  7:22                                                       ` Eli Zaretskii
2019-02-02  3:25                                                         ` Richard Stallman
2019-02-02  7:22                                                           ` Eli Zaretskii
2019-02-03  4:36                                                             ` Richard Stallman
2019-01-28  3:38                                         ` Eli Zaretskii
2019-01-28  4:13                                           ` Paul Eggert
2019-01-28  6:28                                             ` Daniel Colascione
2019-01-28 15:35                                             ` Eli Zaretskii
2019-01-28 15:57                                               ` Paul Eggert
2019-01-28 16:02                                                 ` Daniel Colascione
2019-01-28 17:39                                                   ` Paul Eggert
2019-01-28 19:46                                                     ` Daniel Colascione [this message]
2019-01-28  8:53                                         ` Stefan Monnier
2019-01-28 12:57                                           ` Fu Yuan
2019-01-28 15:41                                           ` Eli Zaretskii
2019-01-28 18:20                                             ` Stefan Monnier
2019-01-28 19:53                                               ` Eli Zaretskii
2019-01-28 22:30                                                 ` Stefan Monnier
2019-01-27  9:55           ` Stefan Monnier
2019-01-27 10:32             ` Andreas Schwab
2019-01-27 10:44               ` Stefan Monnier
2019-01-27 10:54                 ` Andreas Schwab
2019-01-27 15:33                   ` Eli Zaretskii
2019-01-27 18:52                     ` Stefan Monnier
2019-01-27 19:25                       ` Eli Zaretskii
2019-01-27 18:47                   ` Stefan Monnier
2019-01-26 17:27         ` Michael Heerdegen
2019-01-26 17:29           ` Eli Zaretskii
2019-01-26 18:05             ` Michael Heerdegen
2019-01-26 18:13               ` Eli Zaretskii
2019-01-26 20:05                 ` Michael Heerdegen
2019-01-26 20:43                   ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2019-01-30  3:00 Van L

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=f0549e9574b762d937ed42c661dd61c8.squirrel@dancol.org \
    --to=dancol@dancol.org \
    --cc=eggert@cs.ucla.edu \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=rpluim@gmail.com \
    --cc=schwab@linux-m68k.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).