Subject: Re: bug#78162: [PATCH] hash-table-contains-p: Avoid creating a symbol on every call

From: Pip Cet <[email-masked]>
Date: Sun, 11 May 2025 09:44:46 +0000

"Stefan Monnier" <[email-masked]> 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