-
Notifications
You must be signed in to change notification settings - Fork 259
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
feat: use leantar
in lake exe cache
#5710
Conversation
All working for me now, and a massive speedup:
|
Oh wow, I just had the pleasure of running |
This PR/issue depends on:
|
bors merge |
This hooks up the new `leantar` tool from https://github.com/digama0/leangz to `lake exe cache`. It uses an olean compressor to achieve much smaller file sizes, and faster decompression. See the [Zulip discussion](https://leanprover.zulipchat.com/#narrow/stream/270676-lean4/topic/leangz.3A.20olean.20file.20compressor/near/369738648). The new files have a new file extension, `123.ltar` instead of `123.tar.gz`. This implementation does not multiplex between them, so it will be a hard reset. In fact, the new cache doesn't even know how to clear the old cache files, so you might need to do that manually. Switching between branches will still work during the interim, since the cache will have both kinds of file and use the right ones.
Pull request successfully merged into master. Build succeeded! The publicly hosted instance of bors-ng is deprecated and will go away soon. If you want to self-host your own instance, instructions are here. If you want to switch to GitHub's built-in merge queue, visit their help page. |
leantar
in lake exe cache
leantar
in lake exe cache
This reverts commit 6ed1d66.
leantar
in lake exe cache
leantar
in lake exe cache
This reverts commit 6ed1d66. Currently broken on gitpod (needs `sudo apt-get install xz-utils`) and on Windows (likely the same issue). Co-authored-by: Scott Morrison <scott.morrison@gmail.com>
s!"https://github.com/digama0/leangz/releases/download/v{LEANTARVERSION}/leantar-v{LEANTARVERSION}-{target}.{ext}", | ||
"-L", "-o", s!"{LEANTARBIN}.{ext}"] | ||
let _ ← runCmd "tar" #["-xf", s!"{LEANTARBIN}.{ext}", | ||
"-C", IO.CACHEDIR.toString, "--strip-components=1"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this work on windows (i.e., with zip)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems to work... not sure how universally available tar
is on windows but this exact command was tested and works on at least a few machines. (The old cache was also using tar
for unpacking on windows and I don't think we have received any complaints about it.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😱
The old cache was also using tar for unpacking on windows and I don't think we have received any complaints about it.
The old cache used tar to unpack tar files. This line here uses tar to unpack zip files. But if it works. 🤷
I am happy with the static linking issue now. The branch works fine on nixos. @fpvandoorn complained about windows performance on zulip. Is this still an issue (is it even a regression) and is there something we can do about it? |
We investigated it and it doesn't seem like there is much we can do about it, the bottleneck is the write itself and I think windows is just slow at writing lots of files. I don't think it is a regression compared to the original |
When testing a bit more carefully yesterday, I think now that |
bors r+ |
Already running a review |
bors seems to not be working. I'll try again. |
bors r- |
bors merge |
Already running a review |
Seems to be resolved, and I'm dismissing this in case it is interacting with the strange bors behaviour.
I think bors is failing here because it has already merged this PR once (my fault, I merged too early and had to revert). I'm just going to squash merge now. |
This hooks up the new `leantar` tool from https://github.com/digama0/leangz to `lake exe cache`. It uses an olean compressor to achieve much smaller file sizes, and faster decompression. See the [Zulip discussion](https://leanprover.zulipchat.com/#narrow/stream/270676-lean4/topic/leangz.3A.20olean.20file.20compressor/near/369738648). The new files have a new file extension, `123.ltar` instead of `123.tar.gz`. This implementation does not multiplex between them, so it will be a hard reset. In fact, the new cache doesn't even know how to clear the old cache files, so you might need to do that manually. Switching between branches will still work during the interim, since the cache will have both kinds of file and use the right ones.
This reverts commit 6ed1d66. Currently broken on gitpod (needs `sudo apt-get install xz-utils`) and on Windows (likely the same issue). Co-authored-by: Scott Morrison <scott.morrison@gmail.com>
* feat: use `leantar` in `lake exe cache` * run pack in parallel * bump leantar * version check * use hex for hashes * chore: bump to 0.1.2, add .exe on windows * fix: file extension on linux * fix: arch is reported as arm64 sometimes * fix: statically linked 0.1.3
This hooks up the new
leantar
tool from https://github.com/digama0/leangz tolake exe cache
. It uses an olean compressor to achieve much smaller file sizes, and faster decompression. See the Zulip discussion.The new files have a new file extension,
123.ltar
instead of123.tar.gz
. This implementation does not multiplex between them, so it will be a hard reset. In fact, the new cache doesn't even know how to clear the old cache files, so you might need to do that manually. Switching between branches will still work during the interim, since the cache will have both kinds of file and use the right ones.