Please sign in to comment.
remove a mis-optimization that hurt performance for uneven updates
If the total number of chunks hashed so far is e.g. 1, and update() is called with e.g. 8 more chunks, we can't compress all 8 together. We have to break the input up, to make sure that that 1 lone chunk CV gets merged with its proper sibling, and that in general the correct layout of the tree is preserved. What we should do is hash 1-2-4-1 chunks of input, using increasing powers of 2 (with some cleanup at the end). What we were doing was 2-2-2-2 chunks. This was the result of a mistaken optimization that got us stuck with an always-odd number of chunks so far. Fixes #69.
- Loading branch information
Showing with 71 additions and 18 deletions.