[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Should we land Lisp reader optimizations?
From: |
John Wiegley |
Subject: |
Re: Should we land Lisp reader optimizations? |
Date: |
Wed, 21 Jun 2017 23:25:41 -0700 |
User-agent: |
Gnus/5.130016 (Ma Gnus v0.16) Emacs/25.2.50 (darwin) |
>>>>> "ms" == michael schuldt <address@hidden> writes:
ms> But in either case Ken seems to make it clear that it does not really
ms> matter - GC overhead is small when reading normal files and already
ms> minimized for the big .elc read
And in fact, the GC can make things faster, by quickly freeing temporarily
allocated memory that can be reused in a subsequent loop iteration. Although
it does take "work" to walk the heap and free objects, sometimes this work is
less than freshly allocating new temporary blocks at ever-new places on the
heap.
--
John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2
- Re: Should we land Lisp reader optimizations?, (continued)
- Re: Should we land Lisp reader optimizations?, Ken Raeburn, 2017/06/20
- Re: Should we land Lisp reader optimizations?, John Wiegley, 2017/06/20
- Re: Should we land Lisp reader optimizations?, michael schuldt, 2017/06/20
- Re: Should we land Lisp reader optimizations?, Ken Raeburn, 2017/06/21
- Re: Should we land Lisp reader optimizations?, Eli Zaretskii, 2017/06/21
- Re: Should we land Lisp reader optimizations?, Richard Stallman, 2017/06/21
- Re: Should we land Lisp reader optimizations?, michael schuldt, 2017/06/21
- Re: Should we land Lisp reader optimizations?,
John Wiegley <=
- Re: Should we land Lisp reader optimizations?, Stefan Monnier, 2017/06/22
- Re: Should we land Lisp reader optimizations?, Richard Stallman, 2017/06/21
- Re: Should we land Lisp reader optimizations?, Ken Raeburn, 2017/06/21
- Re: Should we land Lisp reader optimizations?, Eli Zaretskii, 2017/06/21