-
Notifications
You must be signed in to change notification settings - Fork 4k
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
Execution log + remote cache = very long build time #23319
Comments
Consider using |
@tjgq , I tries |
Could you share two trace profiles (`--profile`) for your build, with and
without the compact execution log enabled, so I could better understand
where the time is going? Ideally for a build where actions are all hitting
the disk cache, which is the worst case for the execution log (very little
work happening elsewhere).
Also, how big is the execution log (in compact format)?
…On Fri, Aug 16, 2024 at 13:47 Evgenii Oparin ***@***.***> wrote:
@tjgq <https://github.com/tjgq> , I tries
--experimental_execution_log_compact_file on bazel 7.2.0. General
behavior is the same.
—
Reply to this email directly, view it on GitHub
<#23319 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABBK5HIACUVO52V34KT3U3LZRXYE7AVCNFSM6AAAAABMTSFJ2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJTGQ2DQMBVGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
It looks like these are for the json format. Can you also capture a profile for the compact format under the same conditions?
This shouldn't be the case for a typical build. The zstd compression is not the only difference between the two formats; the compact format avoids redundant work in other ways. (It's possible that your build is atypical, which is why I'd like to see both profiles). |
@tjgq , performance with |
Thanks for checking that the compact format works for you! I will close this issue, as I don't think it's possible to improve performance for the json/binary formats. The way forward is to point people to the compact format and deprecate them. |
Description of the bug:
Official way of cache hit debugging is based on execution logs gathering cache-remote.
However if we build with execution_logs ON and remote_cache ON build time increases dramatically (x2-x5).
Which category does this issue belong to?
No response
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
I have a target of 30 build actions (cpp code + packaging).
Build time average (sec):
no options:___________________________________28
disk cache in ON:_____________________________13
execution json log is ON:_____________________28
execuion json log is ON, disk cache is ON:___59
Disk cache is ON build shows repos fetching time. If bare in mind this,
(execuion json log is ON + disk cache is ON) / execution json log is ON = 46 / 15 = 3 times
Which operating system are you running Bazel on?
Windows
What is the output of
bazel info release
?7.0.2
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse HEAD
?No response
If this is a regression, please try to identify the Bazel commit where the bug was introduced with bazelisk --bisect.
No response
Have you found anything relevant by searching the web?
No response
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: