Well this is expected since you didn’t include the extra time it takes to init the BufferedTriples, no? The more you get to re-use the same instances the more beneficial this is.
you didn’t include the extra time it takes to init the BufferedTriples, no?
I did not. However, once you have the hash value, you can re-use many times.
I do not advocate pre-computing the hash values in general.
Michel Lemaysays:
Hi Daniel, I find your post interesting and I observed similar measurements. However, you still have to compute the hash value, be it in the constructor of your object or at lookup time. So unless you reuse the same object instances over and over, you will just move the computation on a different code path. In the last few cases where I had to profile hashmap lookups, it was with caches. I would check if a given key object (tuple of something) would exists in the cache. In this typical use case, keys are rarely available in final form and must be constructed at the point of lookup and dominate execution time.
Though you are correct, I think it is a bit less trivial than what your arguments might imply. If you try running my tests (Swift runs well on Linux), you’ll notice that I record the time required to construct Triples and BufferedTriples and the difference is small.
Yvosays:
What would be a good way to cache the hash value using the new Hasher protocol? The hashValue int will probably eventually be deprecated.
Well this is expected since you didn’t include the extra time it takes to init the BufferedTriples, no? The more you get to re-use the same instances the more beneficial this is.
you didn’t include the extra time it takes to init the BufferedTriples, no?
I did not. However, once you have the hash value, you can re-use many times.
I do not advocate pre-computing the hash values in general.
Hi Daniel, I find your post interesting and I observed similar measurements. However, you still have to compute the hash value, be it in the constructor of your object or at lookup time. So unless you reuse the same object instances over and over, you will just move the computation on a different code path. In the last few cases where I had to profile hashmap lookups, it was with caches. I would check if a given key object (tuple of something) would exists in the cache. In this typical use case, keys are rarely available in final form and must be constructed at the point of lookup and dominate execution time.
Though you are correct, I think it is a bit less trivial than what your arguments might imply. If you try running my tests (Swift runs well on Linux), you’ll notice that I record the time required to construct Triples and BufferedTriples and the difference is small.
What would be a good way to cache the hash value using the new Hasher protocol? The hashValue int will probably eventually be deprecated.