From: Phil Sainty <psainty@orcon.net.nz>
To: emacs-devel@gnu.org
Subject: Performance of lexical closures in interpreted code? (was Re: Execution speed)
Date: Mon, 20 Mar 2017 23:36:49 +1300 [thread overview]
Message-ID: <a9f1fc89-c398-aeea-69e7-b58fdf2e2219@orcon.net.nz> (raw)
In-Reply-To: <b127d5b9-1a63-c7e6-0822-c106020cf2ac@orcon.net.nz>
Tangentially, that performance hit on the interpreted recursive
code with lexical-binding enabled is pretty severe! From well under
2 seconds (with dynamic binding) to well over 4 seconds (with lexical
binding) in all my results.
Is this a known/accepted trade-off for the better byte-compiled
performance? I'm assuming it's to do with overheads of lexical
closures.
The output npostavs generates indicates that it's largely (if
not solely) on account of a vast quantity of garbage collection.
Perhaps that is all the lexical environments being cleaned up?
(Although I would have thought that was a requirement for the
byte-compiled code as well, so I'm very much guessing.)
Can that be improved, or is this most likely to remain this way?
On 20/03/17 11:49, Phil Sainty wrote:
> Using npostavs's code:
>
> | DYNAMIC | interpreted | compiled
> --------------------------------------------------------------------
> 25.2 | recursive | 1.55s | 0.94s
> | iterative | 1.70s | 1.06s
> --------------------------------------------------------------------
> 25.1 | recursive | 1.53s | 0.95s
> | iterative | 1.87s | 1.06s
> --------------------------------------------------------------------
> 24.5 | recursive | 1.65s | 1.24s
> | iterative | 1.43s | 0.95s
> --------------------------------------------------------------------
> 24.4 | recursive | 1.78s | 1.25s
> | iterative | 1.59s | 1.02s
> --------------------------------------------------------------------
>
>
> | LEXICAL | interpreted | compiled
> --------------------------------------------------------------------
> 25.2 | recursive | 4.27s (2.22s in 506 GCs) | 0.64s (0.03s in 6 GCs)
> | iterative | 1.56s (0.10s in 23 GCs) | 0.49s (0.03s in 6 GCs)
> --------------------------------------------------------------------
> 25.1 | recursive | 4.26s (2.21s in 506 GCs) | 0.64s (0.03s in 6 GCs)
> | iterative | 1.58s (0.10s in 23 GCs) | 0.50s (0.03s in 6 GCs)
> --------------------------------------------------------------------
> 24.5 | recursive | 4.11s (2.14s in 507 GCs) | 0.92s (0.03s in 6 GCs)
> | iterative | 1.57s (0.09s in 22 GCs) | 0.84s (0.03s in 7 GCs)
> --------------------------------------------------------------------
> 24.4 | recursive | 4.20s (2.08s in 506 GCs) | 0.91s (0.03s in 6 GCs)
> | iterative | 1.65s (0.10s in 23 GCs) | 0.82s (0.03s in 6 GCs)
> --------------------------------------------------------------------
next prev parent reply other threads:[~2017-03-20 10:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-19 15:12 Execution speed Stefan Monnier
2017-03-19 15:26 ` Mark Oteiza
2017-03-19 15:32 ` Eli Zaretskii
2017-03-19 16:01 ` Tino Calancha
2017-03-19 16:14 ` Andreas Politz
2017-03-19 16:33 ` Teemu Likonen
2017-03-19 19:09 ` npostavs
2017-03-19 22:49 ` Phil Sainty
2017-03-20 10:36 ` Phil Sainty [this message]
2017-03-20 12:50 ` Performance of lexical closures in interpreted code? (was Re: Execution speed) Stefan Monnier
2017-03-20 13:12 ` Stefan Monnier
2017-03-19 22:30 ` Execution speed Phil Sainty
2017-03-20 9:46 ` Ivan Kanis
2017-03-20 10:46 ` Philippe Vaucher
2017-03-20 14:26 ` Filipp Gunbin
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=a9f1fc89-c398-aeea-69e7-b58fdf2e2219@orcon.net.nz \
--to=psainty@orcon.net.nz \
--cc=emacs-devel@gnu.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.