From: Eli Zaretskii <eliz@gnu.org>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: emacs-devel@gnu.org
Subject: Re: Ahead of time compilation?
Date: Sat, 15 Sep 2018 09:57:39 +0300 [thread overview]
Message-ID: <8336ubjli4.fsf@gnu.org> (raw)
In-Reply-To: <20180914181636.3ae6b46b@jabberwock.cb.piermont.com> (perry@piermont.com)
> Date: Fri, 14 Sep 2018 18:16:36 -0400
> From: "Perry E. Metzger" <perry@piermont.com>
>
> Given the recent JIT discussion, it occurs to me that a large
> fraction of the elisp infrastructure in the average emacs is the
> stuff that gets slurped in and undumped. Perhaps all that stuff could
> get ahead of time compiled before undump for performance? Build time
> isn't nearly as relevant for me as speed during execution, and on
> platforms that don't have the infra, the interpreter could continue
> to be use for that stuff.
IMO, before we decide to do this, we should convince ourselves that
JIT in the libjit branch indeed speeds up things significantly enough
for us to bother doing the above. There was contradictory evidence
about that in the past, see recent threads on this list. As one data
point I measured myself, the time it took to byte-compile all of the
Lisp files in the Emacs tree was almost exactly the same with and
without JIT.
Benchmarks of JIT performance as compared to byte-compiled code are
therefore greatly appreciated. For the issue you raise above, I guess
we should try benchmarking code that gets dumped into the Emacs
executable, from preloaded packages; you can see them listed in
loadup.el.
Thanks.
next prev parent reply other threads:[~2018-09-15 6:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-14 22:16 Ahead of time compilation? Perry E. Metzger
2018-09-14 22:25 ` Tom Tromey
2018-09-14 23:52 ` Perry E. Metzger
2018-09-15 2:33 ` Tom Tromey
2018-09-15 6:57 ` Eli Zaretskii [this message]
2018-09-15 21:33 ` Perry E. Metzger
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=8336ubjli4.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=perry@piermont.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.