# Could the usage of \`haskey\` be unidiomatic/inefficient?

**URL:** <https://discourse.julialang.org/t/could-the-usage-of-haskey-be-unidiomatic-inefficient/17442>\
**Category:** Performance\
**Tags:** dictionary\
**Created:** [November 12, 2018, 6:00pm UTC](https://discourse.julialang.org/t/could-the-usage-of-haskey-be-unidiomatic-inefficient/17442 "2018-11-12T18:00:56Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)\
**Post date:** [November 12, 2018, 6:40pm UTC](https://discourse.julialang.org/t/could-the-usage-of-haskey-be-unidiomatic-inefficient/17442/4 "2018-11-12T18:40:22Z")

</div>

Only you can `Profile.@profile` whether this is a perf problem in your specific code. This does cause two lookups, but the first one will fetch the relevant cache-line. So the second lookup only costs CPU and no mem-traffic nor does it have to wait an eternity for main memory.

If profiling shows that the second lookup is a significant part of your time, then my recommendation is `Base.ht_keyindex2!` (look up position of key; -pos if not present; may rehash dict to make space for new element) and `Base.ht_keyindex` (look up position of key, -1 if not present).

The optimizer might be capable of removing the second hash computation. I don’t think that the optimizer will be capable of removing the comparisons (the linear search of all colliding elements).

---

_[View the full topic](https://discourse.julialang.org/t/could-the-usage-of-haskey-be-unidiomatic-inefficient/17442)._