Skip to content
This repository has been archived by the owner on Feb 15, 2024. It is now read-only.

Potential performance optimization on winningNodeForCycleHash #29

Open
EggPool opened this issue Oct 6, 2020 · 0 comments
Open

Potential performance optimization on winningNodeForCycleHash #29

EggPool opened this issue Oct 6, 2020 · 0 comments

Comments

@EggPool
Copy link

EggPool commented Oct 6, 2020

Thanks for the nice algorithm!

Maybe a slight improvement:

if (ByteUtil.arraysAreEqual(ipHash, winningHash)) {

closerHash returns a hash; after scanning all 3 input hashes.
Then the returned hash is only used to compare to ipHash again.
It could be faster to return a boolean hash1IsCloserOrSame(reference, hash0, hash1) and thus avoid the extra hash comparison.

Another option would be to compute distance (reference, hash) only, and store winningDistance along with winningHash
That way for each step you only need one distance computation instead of 2, hash0 being winningHash computed over and over.

Edit: The following is not true after a closer look. I left the comment anyway

Also, in dense regions, 15 tickets are computed 15 times each, while only the last IP can get them.
At the expense of more complex logic, several hash and comparisons could be avoided (unsure of the global perf gain vs code complexity)

Sorry if you already benchmarked these and there is no significant gain.

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

No branches or pull requests

1 participant