Re: The myth of fingerprints, er, no, garbage collectors

"David McClain (as dbm at refined-audiometrics dot com)" <[email protected]> Thu, 25 Jun 2026 09:21:39 -0700
Newsgroups gmane.lisp.lispworks.general
Message-ID <[email protected]>
--Apple-Mail=_E6C08C73-C1B4-4406-AA1F-DC9398C70AEA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

=F0=9F=91=8D

> On Jun 25, 2026, at 09:17, Tim Bradshaw (as tfb at tfeb dot org) =
<[email protected]> wrote:
>=20
> Given this silly function:
>=20
> (defun smash (n m)
>  (declare (type fixnum n m))
>  (let ((c nil))
>    (dotimes (i n c)
>      (setf c (cons 1 (if (zerop (mod i m)) nil c))))))
>=20
> You can time it.  (smash (expt 10 9) 10)) allocates about 16GB, and =
takes 25 seconds.  GC time is about 0.3% of that time.
>=20
> You can also watch GC time grow as it has to copy more: (smash (expt =
10 9) 1000) makes lists which can grow to 1000 elts: GC now is well over =
0.5% of the time.	Keeping lists of a million elements results in =
the GC taking 10% of the runtime.
>=20
> The reason I have been playing with all these things is I keep finding =
myself writing functions which carefully allow you to, for instance pass =
in some object which they will then reuse instead of allocating one.  =
And after trying to measure if this was worthwhile, I realised that it =
almost never is: it's better to allocate the thing on the fly and throw =
it away, because the GC will then never see it at all, whereas if you =
hold onto it, it will.
>=20
> As someone who remembers when a GC meant 'you can go and make a cup of =
tea now', modern GCs are wonderful things: we forget how spoiled we are.
>=20
> --tim
>=20
> _______________________________________________
> Lisp Hug - the mailing list for LispWorks users
> [email protected]
> http://www.lispworks.com/support/lisp-hug.html


--Apple-Mail=_E6C08C73-C1B4-4406-AA1F-DC9398C70AEA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" =
content=3D"text/html; charset=3Dutf-8"></head><body =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;"><span =
style=3D"font-size:-webkit-xxx-large">=F0=9F=91=8D</span><br =
id=3D"lineBreakAtBeginningOfMessage"><div><br><blockquote =
type=3D"cite"><div>On Jun 25, 2026, at 09:17, Tim Bradshaw (as tfb at =
tfeb dot org) &lt;[email protected]&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div><div>Given this silly =
function:<br><br>(defun smash (n m)<br> &nbsp;(declare (type fixnum n =
m))<br> &nbsp;(let ((c nil))<br> &nbsp;&nbsp;&nbsp;(dotimes (i n c)<br> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(setf c (cons 1 (if (zerop (mod i m)) nil =
c))))))<br><br>You can time it. &nbsp;(smash (expt 10 9) 10)) allocates =
about 16GB, and takes 25 seconds. &nbsp;GC time is about 0.3% of that =
time.<br><br>You can also watch GC time grow as it has to copy more: =
(smash (expt 10 9) 1000) makes lists which can grow to 1000 elts: GC now =
is well over 0.5% of the time.<span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>Keeping lists of a million =
elements results in the GC taking 10% of the runtime.<br><br>The reason =
I have been playing with all these things is I keep finding myself =
writing functions which carefully allow you to, for instance pass in =
some object which they will then reuse instead of allocating one. =
&nbsp;And after trying to measure if this was worthwhile, I realised =
that it almost never is: it's better to allocate the thing on the fly =
and throw it away, because the GC will then never see it at all, whereas =
if you hold onto it, it will.<br><br>As someone who remembers when a GC =
meant 'you can go and make a cup of tea now', modern GCs are wonderful =
things: we forget how spoiled we =
are.<br><br>--tim<br><br>_______________________________________________<b=
r>Lisp Hug - the mailing list for LispWorks =
users<br>[email protected]<br>http://www.lispworks.com/support/lisp-h=
ug.html<br></div></div></blockquote></div><br></body></html>=

--Apple-Mail=_E6C08C73-C1B4-4406-AA1F-DC9398C70AEA--

_______________________________________________
Lisp Hug - the mailing list for LispWorks users
[email protected]
http://www.lispworks.com/support/lisp-hug.html