all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Florian Weimer <fweimer@redhat.com>
To: Ken Raeburn <raeburn@raeburn.org>, Dmitry Gutov <dgutov@yandex.ru>
Cc: Ali Bahrami <ali_gnu2@emvision.com>, emacs-devel@gnu.org
Subject: Re: Removal of unexec support from glibc malloc
Date: Tue, 19 Jan 2016 08:03:16 +0100	[thread overview]
Message-ID: <569DDFB4.2080301@redhat.com> (raw)
In-Reply-To: <1F560A56-37A2-482D-9010-8733E906FD16@raeburn.org>

[-- Attachment #1: Type: text/plain, Size: 1336 bytes --]

On 01/19/2016 02:44 AM, Ken Raeburn wrote:
> 
>> On Jan 18, 2016, at 20:14, Dmitry Gutov <dgutov@yandex.ru> wrote:
>>
>> On 01/19/2016 01:45 AM, Ali Bahrami wrote:
>>
>>> Before you fight to to save unexec, I'd encourage you to measure the
>>> impact, and see if it still matters.
>>
>> As a rough measurement, 'src/emacs -Q' takes ~0.5s to launch on my machine. 'src/temacs -Q` takes ~5.5s.
>>
>> It seems not only machines have become faster, Emacs has grown quite a bit, too. :)
> 
> It’s also pretty aggressive about garbage collection after loading any code before the unexec.  Presumably that’s to minimize the storage needed for the shared on-disk image.
> 
> Try removing the after-load-functions hook in loadup.el that invokes GC, and the explicit GC calls.  Also maybe bump up gc-cons-threshold by an order of magnitude.  (Just until loading finishes, if you like.)

The attached patch brings down the temacs load time to under 0.5 seconds.

The major offender is find_string_data_in_pure in src/alloc.c, and
setting purify to nil gets rid of that.  Some additional savings come
from removing the after-load-function hook in loadup.el, as you
suggested, but they are comparatively minor.

For some reason, international/characters does not load anymore, so I
dropped it for quick testing.

Florian

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: fast-temacs.patch --]
[-- Type: text/x-patch; name="fast-temacs.patch", Size: 1788 bytes --]

diff --git a/lisp/loadup.el b/lisp/loadup.el
index 5f29c01..8870eb7 100644
--- a/lisp/loadup.el
+++ b/lisp/loadup.el
@@ -47,6 +47,8 @@
 
 ;;; Code:
 
+(setq purify-flag nil)
+
 ;; Add subdirectories to the load-path for files that might get
 ;; autoloaded when bootstrapping.
 ;; This is because PATH_DUMPLOADSEARCH is just "../lisp".
@@ -99,10 +101,6 @@
 (load "emacs-lisp/backquote")
 (load "subr")
 
-;; Do it after subr, since both after-load-functions and add-hook are
-;; implemented in subr.el.
-(add-hook 'after-load-functions (lambda (f) (garbage-collect)))
-
 (load "version")
 
 (load "widget")
@@ -168,7 +166,6 @@
 ;; This file doesn't exist when building a development version of Emacs
 ;; from the repository.  It is generated just after temacs is built.
 (load "international/charprop.el" t)
-(load "international/characters")
 (load "composite")
 
 ;; Load language-specific files.
@@ -374,11 +371,6 @@
 ;; Avoid storing references to build directory in the binary.
 (setq custom-current-group-alist nil)
 
-;; We keep the load-history data in PURE space.
-;; Make sure that the spine of the list is not in pure space because it can
-;; be destructively mutated in lread.c:build_load_history.
-(setq load-history (mapcar 'purecopy load-history))
-
 (set-buffer-modified-p nil)
 
 (remove-hook 'after-load-functions (lambda (f) (garbage-collect)))
@@ -413,10 +405,6 @@
     (message "Pure-hashed: %d strings, %d vectors, %d conses, %d bytecodes, %d others"
              strings vectors conses bytecodes others)))
 
-;; Avoid error if user loads some more libraries now and make sure the
-;; hash-consing hash table is GC'd.
-(setq purify-flag nil)
-
 (if (null (garbage-collect))
     (setq pure-space-overflow t))
 

  parent reply	other threads:[~2016-01-19  7:03 UTC|newest]

Thread overview: 77+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-18 12:33 Removal of unexec support from glibc malloc Florian Weimer
2016-01-18 19:20 ` John Wiegley
2016-01-18 20:27   ` Florian Weimer
2016-01-19 13:52     ` Should Glibc API be changed? Richard Stallman
2016-01-19 16:40       ` Florian Weimer
2016-01-20  2:56         ` Richard Stallman
2016-01-20 17:07           ` Florian Weimer
2016-01-23  5:56     ` Removal of unexec support from glibc malloc Stefan Monnier
2016-01-26 22:08       ` Florian Weimer
2016-01-18 22:45   ` Ali Bahrami
2016-01-18 23:45     ` John Wiegley
2016-01-19  0:45     ` Wolfgang Jenkner
2016-01-19  0:56       ` Ali Bahrami
2016-01-19  1:14     ` Dmitry Gutov
2016-01-19  1:44       ` Ken Raeburn
2016-01-19  1:59         ` Dmitry Gutov
2016-01-19  3:10           ` Ken Raeburn
2016-01-19  3:17             ` Dmitry Gutov
2016-01-19  7:03         ` Florian Weimer [this message]
2016-01-19  8:36           ` Ken Raeburn
2016-01-19 16:42           ` Eli Zaretskii
2016-01-19  1:45       ` Ali Bahrami
2016-01-19  2:03         ` Dmitry Gutov
2016-01-19 16:04         ` Eli Zaretskii
2016-01-20  2:57           ` Richard Stallman
2016-01-20  7:43             ` David Caldwell
2016-01-20  9:35               ` Eli Zaretskii
2016-01-21  3:01                 ` Richard Stallman
2016-01-21  3:00               ` Richard Stallman
2016-01-19 15:58     ` Eli Zaretskii
2016-01-19 20:37       ` Fabrice Popineau
2016-01-20  2:56         ` Richard Stallman
2016-01-23 13:51           ` Michael Sperber
2016-01-23 20:36             ` Marcus Crestani
2016-01-19 23:53   ` Sam Steingold
2016-01-18 19:24 ` Paul Eggert
2016-01-18 19:30   ` John Wiegley
2016-01-18 19:47     ` Daniel Colascione
2016-01-18 19:54       ` Zack Weinberg
2016-01-18 19:55         ` Daniel Colascione
2016-01-18 22:27           ` Joseph Myers
2016-01-18 23:16             ` Florian Weimer
2016-01-18 19:50     ` Paul Eggert
2016-01-18 19:54       ` Daniel Colascione
2016-01-18 20:02       ` Eli Zaretskii
2016-01-18 20:05         ` Daniel Colascione
2016-01-18 22:10           ` Philipp Stephani
2016-01-18 22:12             ` Daniel Colascione
2016-01-18 22:36               ` Óscar Fuentes
2016-01-23  5:50               ` Stefan Monnier
2016-01-18 20:24         ` Wolfgang Jenkner
2016-01-18 20:29           ` Eli Zaretskii
2016-01-18 20:36             ` Wolfgang Jenkner
2016-01-18 22:42           ` Paul Eggert
2016-01-18 23:23             ` Florian Weimer
2016-01-19  6:31               ` Paul Eggert
2016-01-19  9:27                 ` Florian Weimer
2016-01-19 10:14                   ` Florian Weimer
2016-01-19 13:27                 ` Wolfgang Jenkner
2016-01-19 16:58                   ` Eli Zaretskii
2016-01-30  9:38                 ` Paul Eggert
2016-01-18 22:44       ` Florian Weimer
2016-01-19  3:48         ` Eli Zaretskii
2016-01-23  5:49           ` Stefan Monnier
2016-01-23  7:00             ` Eli Zaretskii
2016-01-23 15:29               ` Stefan Monnier
2016-01-23 15:50                 ` Eli Zaretskii
2016-01-23 22:19                   ` Stefan Monnier
2016-01-23 22:52               ` Richard Stallman
2016-01-26 22:17                 ` Florian Weimer
2016-01-27  1:32                   ` Stefan Monnier
2016-01-27  3:38                   ` Eli Zaretskii
2016-01-27  9:04                     ` Florian Weimer
2016-01-27 16:02                       ` Eli Zaretskii
2016-01-27 22:54                     ` Richard Stallman
2016-01-27 22:52                   ` Richard Stallman
2016-01-18 23:15   ` Florian Weimer

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=569DDFB4.2080301@redhat.com \
    --to=fweimer@redhat.com \
    --cc=ali_gnu2@emvision.com \
    --cc=dgutov@yandex.ru \
    --cc=emacs-devel@gnu.org \
    --cc=raeburn@raeburn.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 external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.