all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Philippe Vaucher <philippe.vaucher@gmail.com>
Cc: p.stephani2@gmail.com, eggert@cs.ucla.edu, 23529@debbugs.gnu.org
Subject: bug#23529: Request for fixing randomize_va_space build issues
Date: Tue, 13 Sep 2016 17:47:18 +0300	[thread overview]
Message-ID: <83intz97rd.fsf@gnu.org> (raw)
In-Reply-To: <CAGK7Mr6FOFhxxd71V3Ydi0Dfw7ERr5rDq07jg61WT3nT5Vjv1Q@mail.gmail.com> (message from Philippe Vaucher on Mon, 12 Sep 2016 16:18:11 +0200)

What about this idea:

  https://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01049.html

To recap: the idea is to dump the dumping (pun intended), and instead
load the preloaded packages upon each session start.  This currently
takes about 5 to 12 sec, depending on the platform and the
optimization switches, but a simple optimization brings it down to
below 0.5 sec in an optimized build.  Further testing indicates that
lumping all of the files we preload into a single .elc file reduces
the load time even more, so it becomes around 0.1-0.2 sec.  That
should be short enough to make it negligible, right?

This sounds as a much easier and low-risk approach. Its significant
advantage is that it doesn't require any serious changes in the
low-level infrastructure -- no need for generating C code or dump data
records as part of DEFUN, defsubr, and staticpro, no need to hunt for,
dump, and restore global variables that hold Lisp objects, no
dependencies on external tools, etc.  Almost everything in support of
this method, like the ability to redirect results of compiling several
source files into a single .elc file, can be done in Lisp, mainly in
loadup.el, plus some Makefile changes in the last stages of the build
process.  A much simpler design and higher-level implementation mean
more people could be involved in working on this, testing, and
debugging, instead of relying on a couple of "usual suspects" who are
overloaded anyway.  Having a single .elc file provides a nice bonus of
being able to run Emacs even if the Lisp files are not available.  And
re-dumping can be supported with almost no effort.

If this idea is accepted, the first question to ask is whether we
still need pure storage on modern platforms.  If we do,
find_string_data_in_pure will have to be sped up by using a hash table
or some such.  If pure storage is not needed, purecopy can be a no-op
and find_string_data_in_pure should simply go away, which is of course
much easier.

Comments?





  reply	other threads:[~2016-09-13 14:47 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-13 12:18 bug#23529: Request for fixing randomize_va_space build issues Philippe Vaucher
2016-05-13 15:58 ` Paul Eggert
2016-05-17 16:38   ` Philippe Vaucher
2016-05-18  7:53     ` Philippe Vaucher
2016-05-18  8:21     ` Paul Eggert
2016-05-18  8:44       ` Philippe Vaucher
2016-05-20 17:52         ` Paul Eggert
2016-09-06  9:22           ` Philipp Stephani
2016-09-06 17:21             ` Paul Eggert
2016-09-06 17:40               ` Eli Zaretskii
2016-09-06 17:46                 ` Philippe Vaucher
2016-09-06 17:55                   ` Philipp Stephani
2016-09-06 18:04                     ` Eli Zaretskii
2016-09-06 17:59                   ` Eli Zaretskii
2016-09-06 18:03                     ` Philipp Stephani
2016-09-06 18:32                       ` Eli Zaretskii
2016-09-06 19:01                         ` Philipp Stephani
2016-09-06 18:24                     ` Philippe Vaucher
2016-09-06 19:11                       ` Eli Zaretskii
2016-09-06 18:18                 ` Clément Pit--Claudel
2016-09-06 19:09                   ` Eli Zaretskii
2016-09-06 19:59                     ` Clément Pit--Claudel
2016-09-06 18:44                 ` Paul Eggert
2016-09-06 19:18                   ` Eli Zaretskii
2016-09-06 20:37                     ` Paul Eggert
2016-09-07  7:12                       ` Philippe Vaucher
2016-09-07  7:40                         ` Paul Eggert
2016-09-07 11:01                           ` Philipp Stephani
2016-09-07 14:21                       ` Eli Zaretskii
2016-09-07 16:11                         ` Paul Eggert
2016-09-07 17:10                           ` Eli Zaretskii
2016-09-07 17:40                             ` Paul Eggert
2016-09-07 18:11                               ` Eli Zaretskii
2016-09-07 20:12                                 ` Paul Eggert
2016-09-09  5:40                                   ` Eli Zaretskii
2016-09-09  7:10                                     ` Paul Eggert
2016-09-09  7:50                                       ` Eli Zaretskii
2016-09-09  8:54                                         ` Paul Eggert
2016-09-09  9:09                                           ` Eli Zaretskii
2016-09-09 16:16                                             ` Paul Eggert
2016-09-09 18:45                                               ` Eli Zaretskii
2016-09-09 19:59                                                 ` Paul Eggert
2016-09-10  6:06                                                   ` Eli Zaretskii
2016-09-10  7:52                                                     ` Paul Eggert
2016-09-10 10:19                                                       ` Eli Zaretskii
2016-09-10 23:01                                                         ` Paul Eggert
2016-09-11 15:23                                                           ` Eli Zaretskii
2016-09-11 16:59                                                             ` Paul Eggert
2016-09-11 17:19                                                               ` Eli Zaretskii
2016-09-11 19:32                                                             ` Philippe Vaucher
2016-09-12  2:30                                                               ` Eli Zaretskii
2016-09-12  2:58                                                                 ` Clément Pit--Claudel
2016-09-12  6:09                                                                   ` Philipp Stephani
2016-09-12 17:04                                                                     ` Eli Zaretskii
2016-09-12 14:10                                                                 ` Philippe Vaucher
2016-09-12 14:18                                                                   ` Philippe Vaucher
2016-09-13 14:47                                                                     ` Eli Zaretskii [this message]
2016-09-13 15:21                                                                       ` Philippe Vaucher
2016-09-13 15:55                                                                         ` Eli Zaretskii
2016-09-13 15:51                                                                       ` Paul Eggert
2016-09-13 19:24                                                                         ` Eli Zaretskii
2016-09-09 20:00                                               ` Philippe Vaucher
2016-09-10  6:13                                                 ` Eli Zaretskii
2016-09-09 18:29                                     ` Andreas Schwab
2016-09-09 18:56                                       ` Eli Zaretskii
  -- strict thread matches above, loose matches on Subject: below --
2019-09-14  4:18 bug#13964: " Stefan Kangas
2019-09-14  8:52 ` Philippe Vaucher
2019-09-14 10:39   ` Stefan Kangas

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=83intz97rd.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=23529@debbugs.gnu.org \
    --cc=eggert@cs.ucla.edu \
    --cc=p.stephani2@gmail.com \
    --cc=philippe.vaucher@gmail.com \
    /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.