-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
remote/performance: don't construct a merkle tree for remote caching #4839
Comments
buchgr
changed the title
discussion: don't construct a merkle tree for remote caching
remote/discussion: don't construct a merkle tree for remote caching
Mar 14, 2018
buchgr
changed the title
remote/discussion: don't construct a merkle tree for remote caching
remote/performance: don't construct a merkle tree for remote caching
Mar 14, 2018
building a merkle tree should not be much more expensive than building a list if implemented correctly. |
Does this still hold true compared to the comment mentioned here: #7583 (comment)? |
I don't know. You'd have to benchmark the current merkle tree implementation against a list based approach I guess. I'd expect the list based approach to still be faster but I am not sure whether it's by a lot. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Remote caching doesn't benefit from constructing a merkle. Some users reported significant performance overheads from constructing the merkle tree. We might just want to compute the hash of the list of input file hashes instead.
cc: @benjaminp
The text was updated successfully, but these errors were encountered: