You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, hashn() allocates a new slice of the hash values and returns it. This causes an allocation that we could get rid of if we instead chose to return h1 and h2 and let the caller compute the different hash values.
This changes the callers from
for i, pos := range hashn(h, d, w) {
to
h1, h2 := hashn(h)
for i := 0; i < d; i++ {
pos := (h1 + uint32(i)*h2) % uint32(w)
Removing these allocations In my tests this speeds up the hashing code by a factor of 2 (~1500ns/op to ~750ns/op).
I have a patch that does this, but it touches a bunch of code so I thought I'd clear this with you before pushing.
The text was updated successfully, but these errors were encountered:
The previous implementation of hashn() return a slice of ints, requiring
an allocation. This made sense when the hashing algorithms were more
complex, but since they're just linear combinations, we can do that in
the caller instead. This removes an allocation which ends up doubling
the speed of the hash function: from ~1500ns/op to ~750ns/op.
Fixes issue #6.
Currently, hashn() allocates a new slice of the hash values and returns it. This causes an allocation that we could get rid of if we instead chose to return h1 and h2 and let the caller compute the different hash values.
This changes the callers from
to
Removing these allocations In my tests this speeds up the hashing code by a factor of 2 (~1500ns/op to ~750ns/op).
I have a patch that does this, but it touches a bunch of code so I thought I'd clear this with you before pushing.
The text was updated successfully, but these errors were encountered: