GNU bug report logs - #78162
[PATCH] hash-table-contains-p: Avoid creating a symbol on every call

Previous Next

Full log

View this message in rfc822 format

From: Pip Cet <pipcet <at> protonmail.com>
To: 78162 <at> debbugs.gnu.org, Daniel Mendler <mail <at> daniel-mendler.de>, Stefan Kangas <stefankangas <at> gmail.com>
Subject: bug#78162: [PATCH] hash-table-contains-p: Avoid creating a symbol on every call
Date: Wed, 30 Apr 2025 11:41:23 +0000

"Daniel Mendler via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs <at> gnu.org> writes:

> Tags: patch
>
> For performance reasons avoid creating a symbol on every call to
> `hash-table-contains-p'.  See also https://github.com/emacs-compat/compat/issues/71.

If the performance of hash-table-contains-p is an issue, we should
reimplement it in C, which can use magic values which aren't accessible
from Lisp.

Exposing the magic value to Lisp will cause trouble, even if it's "just"
a defconst as in your patch.  The current code is somewhat inefficient
but seems to me to be correct.  Even using an uninterned symbol using
its special read syntax (#:missing) may be a problem because of the
position table the reader sometimes keeps.

I say the code "seems" to be correct because depending on how the
defsubst is inlined, an environment may be accessible to the debugger in
which the magic value is leaked.  Byte-compiling the function results in
code which never leaks the value to Lisp, so in practice there shouldn't
be a problem once subr.elc exists.  (As the problem is the defun, not
the bytecode, turning the defsubst into a defun wouldn't help).

My guess is most code using hash-table-contains-p will be inefficient
anyway, because it will either attempt to retrieve the entry, to create
a new entry, or to remove the entry, all of which mean we have to hash
the key again.  All of that can be optimized, of course.

Pip

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.