4 ms·

But why? We have an emacs init process that is fast enough, why not put your init script in version control and bootstrap emacs this way?

Jtsummers 10y ago
Emacs has two init stages, you only see the latter. The first is what gets it to the dump file. The second is where your personal .emacs file gets loaded and executed. The first is the one that takes too long and motivated them to create the dumper system to begin with, and needs some resolution (elimination and making that first init process faster, switching to a serialization of the objects rather than the C program memory, or something else).
- branchless 10y ago
  So am I using this dumper system every time I launch emacs? I start emacs "normally" in that I simply launch it from the cmd line with the daemon flag.
  - vilhelm_s 10y ago
    The binary you launch from the command line was produced by the dumper. The dumping only happens once, when you build emacs from source.
  - deleted 10y ago
    [deleted]
  - Jtsummers 10y ago
    In a sense, yes. You're using the product of the dumper. It's used to create an image of the state of the running system during the emacs build, and then delivered to end users like us as part of the emacs installation. That executable image state is loaded, and then your .emacs is called. For a comparable model, check out the way Smalltalk images (particularly with Squeak and now Pharo) are distributed. For kicks, try running "emacs-undumped". It's the base version without everything loaded (the dump-file), and part of what's used for creating the dump file during the emacs build process. At least for me it's pretty much unusable thanks to the terminal colors that it seems to insist on using for plain text.
    - branchless 10y ago
      Fascinating, thanks. I wonder what the startup ratio is for emacs without the dump vs emacs -q. I build emacs from src from gnu savannah and I have no emacs-undumped btw.
      - Jtsummers 10y ago
        That was on OS X. No idea if it shows up on other systems. The man page says it's not meant for end users like us, and that it's to be used with dumpemacs.

Jtsummers 10y ago

Emacs has two init stages, you only see the latter. The first is what gets it to the dump file. The second is where your personal .emacs file gets loaded and executed. The first is the one that takes too long and motivated them to create the dumper system to begin with, and needs some resolution (elimination and making that first init process faster, switching to a serialization of the objects rather than the C program memory, or something else).

branchless 10y ago
So am I using this dumper system every time I launch emacs? I start emacs "normally" in that I simply launch it from the cmd line with the daemon flag.
- vilhelm_s 10y ago
  The binary you launch from the command line was produced by the dumper. The dumping only happens once, when you build emacs from source.
- deleted 10y ago
  [deleted]
- Jtsummers 10y ago
  In a sense, yes. You're using the product of the dumper. It's used to create an image of the state of the running system during the emacs build, and then delivered to end users like us as part of the emacs installation. That executable image state is loaded, and then your .emacs is called. For a comparable model, check out the way Smalltalk images (particularly with Squeak and now Pharo) are distributed. For kicks, try running "emacs-undumped". It's the base version without everything loaded (the dump-file), and part of what's used for creating the dump file during the emacs build process. At least for me it's pretty much unusable thanks to the terminal colors that it seems to insist on using for plain text.
  - branchless 10y ago
    Fascinating, thanks. I wonder what the startup ratio is for emacs without the dump vs emacs -q. I build emacs from src from gnu savannah and I have no emacs-undumped btw.
    - Jtsummers 10y ago
      That was on OS X. No idea if it shows up on other systems. The man page says it's not meant for end users like us, and that it's to be used with dumpemacs.