Optimize CcInfo computation

[dzbarsky]

This shows up around 4% of buildbuddy analysis phase

After this change, it goes away.

It seems like Bazel is able to make this lazy, which is good since it's only used for building LINKMODE_C_ARCHIVE/LINKMODE_C_SHARED which is fairly rare.

What type of PR is this?
Performance improvement

What does this PR do? Why is it needed?
Avoid computing CcInfo for every intermediate library when it's not needed

Which issues(s) does this PR fix?

Fixes #

Other notes for review

[fmeum]

I'm surprised to see that this reduces CPU usage as I would have expected the aspect to be evaluated eagerly. Could you check the memory implications of having a new aspect?

[dzbarsky]

I'm surprised to see that this reduces CPU usage as I would have expected the aspect to be evaluated eagerly. Could you check the memory implications of having a new aspect?

I did as well, but I guess it must be lazy somehow? (And if it's not, I think we have a path to make it so; the go_binary macro already splits to 2 rules for executable vs non-executable, and we only need the aspect on the non-executable one)

I'll poke at memory usage as well

[dzbarsky]

I'm surprised to see that this reduces CPU usage as I would have expected the aspect to be evaluated eagerly. Could you check the memory implications of having a new aspect?

I did as well, but I guess it must be lazy somehow? (And if it's not, I think we have a path to make it so; the go_binary macro already splits to 2 rules for executable vs non-executable, and we only need the aspect on the non-executable one)

I'll poke at memory usage as well

@fmeum so I tried bazel shutdown && bazel build --nobuild //... && bazel info used-heap-size-after-gc on buildbuddy repo. I saw 215-216MB as baseline, and 220MB with this PR. I made the aspect only apply to non-executable binary and now it is down to 213-214MB, so it's actually an improvement :)

[fmeum]

Great job!