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

Unnecessary Cache Misses on Extra Actions #13029

Closed
cpsauer opened this issue Feb 14, 2021 · 3 comments
Closed

Unnecessary Cache Misses on Extra Actions #13029

cpsauer opened this issue Feb 14, 2021 · 3 comments
Labels

Comments

@cpsauer
Copy link
Contributor

cpsauer commented Feb 14, 2021

Description of the problem / feature request:

There seem to be issues with caching the outputs of extra actions.

As an example, building :A, then :B, then :A again (with action listeners/extra actions) will lead to all the extra actions for :A being rerun. I would expect it to hit cache; there have been no code changes and all the anticipated outputs are already in bazel-out. I can get it to hit those same cached outputs when I issue the same command twice, but alternating leads to unnecessary cache misses.

There seems to be a broader problem here. #4824 lists a narrower case, but then discussion expands into other things that should be hits instead of misses.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

I think the fastest would be to just grab Kythe and alternate running it's action listeners on different targets. You could also quickly modify my minimal example in #12875 if you want something smaller.

Characteristics of the private setup where I initially observed the setup that I don't think matter: Compiling C++, switching between compiling the same code for iOS and android binaries.

What operating system are you running Bazel on?

macOS 11.2

What's the output of bazel info release?

4.0.0

Any other information, logs, or outputs that you want to share?

I've since switched over to aquery instead of action_listener--both to get around some issues and because there's uncertainty about whether extra actions will be supported into the future. There's mention of a deprecation plan years ago in #4824 and it's been marked experimental for a long time, but I didn't see any further details. It'd be great to get an update on what's planned for action listener!

Also tangentially related: It's rather hard to use the output of action_listener because it doesn't expose its outputs, and accumulates outputs across runs in bazel-out. Perhaps I'm missing something, but I didn't see a way to determine which are fresh and from a given build.

@aiuto aiuto added untriaged team-Performance Issues for Performance teams labels Feb 19, 2021
@DavidGoldman
Copy link
Contributor

Can you provide a concrete example (repro + bazel command to reproduce)? If you instead do bazel build //:A && bazel shutdown && bazel build //:A do you see the same issue?

@cpsauer
Copy link
Contributor Author

cpsauer commented Jun 19, 2021

Yikes, so I've stripped down a minimal example and it doesn't reproduce. I promise this is a real thing, but the original code that triggered it is long gone (since I switched approaches to aquery). Sorry. It probably needs a more transitive case to trip it, like the other issue linked.

I think the next move is to just play around with Kythe and see if you can get it to repro. But I'd like to tap out if that's okay. I wrote up this issue--and the others--because I could see Google tooling (e.g. Kythe) that was relying on the api, but I'm no longer using the action_listeners, there are definitely some more general issues with them, and it's unclear what Bazel's future plan is for action_listeners.

@cpsauer cpsauer removed their assignment Jun 24, 2021
@meisterT
Copy link
Member

I tried but couldn't repro, so I am closing this issue. Feel free to comment again if you have new data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants