Skip to content
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

Closed
buchgr opened this issue Mar 13, 2018 · 3 comments
Closed

remote/performance: don't construct a merkle tree for remote caching #4839

buchgr opened this issue Mar 13, 2018 · 3 comments

Comments

@buchgr
Copy link
Contributor

buchgr commented Mar 13, 2018

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

@buchgr 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 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
@buchgr buchgr closed this as completed Feb 5, 2019
@buchgr
Copy link
Contributor Author

buchgr commented Feb 5, 2019

building a merkle tree should not be much more expensive than building a list if implemented correctly.

@Globegitter
Copy link

Does this still hold true compared to the comment mentioned here: #7583 (comment)?

@buchgr
Copy link
Contributor Author

buchgr commented May 14, 2019

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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants