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

Previous Next

Package: emacs;

Reported by: Daniel Mendler <mail <at> daniel-mendler.de>

Date: Wed, 30 Apr 2025 10:04:02 UTC

Severity: normal

Tags: patch

Done: Stefan Monnier <monnier <at> iro.umontreal.ca>

Bug is archived. No further changes may be made.

Full log


Message #35 received at 78162 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Daniel Mendler <mail <at> daniel-mendler.de>,
 Stefan Kangas <stefankangas <at> gmail.com>, 78162 <at> debbugs.gnu.org
Subject: Re: bug#78162: [PATCH] hash-table-contains-p: Avoid creating a symbol
 on every call
Date: Sun, 11 May 2025 09:44:46 +0000
"Stefan Monnier" <monnier <at> iro.umontreal.ca> writes:

>> In any case, IMHO, it's not the magic value that's the problem here,
>> it's that it's stored as a global symbol's value and thus becomes
>> reachable via the obarray.
>
> Then an alternative would be the simpler patch below?

I tried hard to find something wrong with it, but couldn't.

The debugging experience when single-stepping through that function
isn't very good, but that's a separate bug (the debugger should probably
bind print-gensym).

I have no opinion on make-symbol vs #: syntax.  As it's all evaluated
prior to dumping, it doesn't matter much how we construct the symbol: we
dump the final byte code, which looks good to me.

> [ Ideally, this function would be replaced with one which doesn't return
>   just `t` but an actual "handle" on the hash-table slot, so that we can
>   then access that slot without redoing the key lookup.  It would allow
>   doing thing like `push` or `incf` on a hash-table entry without
>   looking up the key twice.
>   But doing so without allocating an object is hard with the current
>   hash-table design (and would come with its own downsides).  ]

I think the low-hanging fruit is probably changing the hash table
implementation so it caches the last key looked up and its index, but
even that minor complication hasn't been necessary so far, I think.

This might change if we make sxhash more resilient against hash
collisions by increasing SXHASH_MAX_DEPTH or SXHASH_MAX_LENGTH.

Pip





This bug report was last modified 12 days ago.

Previous Next


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