all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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)
> --------------------------------------------------------------------



  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.