[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Performance of lexical closures in interpreted code? (was Re: Execution
From: |
Phil Sainty |
Subject: |
Performance of lexical closures in interpreted code? (was Re: Execution speed) |
Date: |
Mon, 20 Mar 2017 23:36:49 +1300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 |
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)
> --------------------------------------------------------------------
- Execution speed, Stefan Monnier, 2017/03/19
- Re: Execution speed, Mark Oteiza, 2017/03/19
- Re: Execution speed, Eli Zaretskii, 2017/03/19
- Re: Execution speed, Tino Calancha, 2017/03/19
- Re: Execution speed, Andreas Politz, 2017/03/19
- Re: Execution speed, Teemu Likonen, 2017/03/19
- Re: Execution speed, npostavs, 2017/03/19
Re: Execution speed, Phil Sainty, 2017/03/19
Re: Execution speed, Ivan Kanis, 2017/03/20
Re: Execution speed, Filipp Gunbin, 2017/03/20