Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

store into the first available empty slot in OpenHashMap probe #9520

Closed
scabug opened this issue Oct 15, 2015 · 5 comments
Closed

store into the first available empty slot in OpenHashMap probe #9520

scabug opened this issue Oct 15, 2015 · 5 comments

Comments

@scabug
Copy link

scabug commented Oct 15, 2015

When OpenHashMap.put(key, hash, value) probes for a slot, if it finds one already occupied by key (and its hash), it uses that, else it uses the first empty slot. The shortcoming of this algorithm is that get() will potentially have to probe over many deleted entries to find the desired key.

We can shorten this search by instead, in put(), storing into the first slot found in the probe sequence that was either deleted, or that contains the current value of the key; or into the first empty slot (but now only if no deleted slot nor current value was found first).

This implies that if a slot holding an old entry (current or deleted) for the key was found, it will not be used if there was a deleted slot preceding it in the probe sequence. It also implies that, if no entry (current or deleted) for the key was found, the empty slot may not necessarily be used—an earlier, deleted slot from another key would be preferred.

The idea is from Knuth, The art of computer programming, 2nd ed., v. 3, (1998), p. 533: "can be inserted in place of the first deleted or empty position that was encountered."

@scabug
Copy link
Author

scabug commented Oct 15, 2015

Imported From: https://issues.scala-lang.org/browse/SI-9520?orig=1
Reporter: Mike (mike)
Assignee: Mike (mike)
Affected Versions: 2.11.7
See #9513

@scabug
Copy link
Author

scabug commented Oct 15, 2015

@Ichoran said:
What is the evidence that this is an important change? (E.g. where does OpenHashMap outperform both HashMap and AnyRefMap?)

@scabug
Copy link
Author

scabug commented Oct 15, 2015

Mike (mike) said:
I didn't claim that it's an important change—rather, it's a "Minor" "Improvement"—or that OpenHashMap outperforms both HashMap and AnyRefMap.

I am aware of your earlier comment criticizing OpenHashMap, and this and SI-9513 should address that. But, unlike in that thread, the goal is to make OpenHashMap faster, not to replace another implementation class.

@scabug
Copy link
Author

scabug commented Oct 16, 2015

Mike (mike) said:
Will need #9522.

@scabug
Copy link
Author

scabug commented Apr 25, 2016

Mike (mike) said:
scala/scala#5124 also addresses this issue for 2.12.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant