It is not just resizing, it could also have been rehashed, which can happen after a GC for eq? hash tables. The conditions under which a single lookup is sufficient will have to be studied carefully in order to optimize that case. So for now a double lookup seems like the easy path forward.
Marc
On Oct 26, 2019, at 4:34 PM, Dimitris Vyzovitis vyzo@hackzen.org wrote:
Couldn't it check whether there has been resize in between and avoid the second lookup if there hasn't been one?
-- vyzo
On Sat, Oct 26, 2019 at 11:31 PM Marc Feeley feeley@iro.umontreal.ca wrote: I’m currently reimplementing tables, so it is a good time to consider this.
However, the “obvious” implementation which does one lookup will not work because the update procedure may cause the gc hash table to be resized. So a lookup must be done before and after the update procedure is executed. However it is possible to avoid repeating some type checks.
Marc
On Oct 26, 2019, at 12:45 PM, Dimitris Vyzovitis vyzo@hackzen.org wrote:
Marc,
Can we add a table-update! primitive? Updates are currently slow because they need two lookups in the hash table, one to find the current value (if any) and one to set it. The canonical signature is (table-update! table key update default), where update is applied to the current value, using default if the value is unset.
-- vyzo