sound: Cache bps in pcm/feeder_eq.c

[christos]

Summary

This value remains stable, so cache it to avoid unnecessary
computations.

Sponsored by: The FreeBSD Foundation
MFC after: 1 week

[dev_submerge.ch]

Why not just cache it in a local variable? That's probably cheaper, even though the "computation" here is trivial anyway.

[markj]

I'm skeptical that this change makes any measurable difference. And, as suggested, it'd be more natural to cache the value in a local variable instead, assuming that the compiler doesn't recognize that the value is constant and hoist that computation out the loop (which would make this diff even less useful).

sys/dev/sound/pcm/feeder_eq.c

277

Shouldn't this be info->bps = AFMT_BPS(info->fmt)? It's not clear to me that these are the same.

[christos]

Cache bps in a local variable.

[markj]

In D48034#1095816, @markj wrote:

as suggested, it'd be more natural to cache the value in a local variable instead, assuming that the compiler doesn't recognize that the value is constant and hoist that computation out the loop (which would make this diff even less useful).

Does this diff actually change the generated code? We should avoid these kinds of microoptimizations unless they can be proven to be useful.

[christos]

In D48034#1096475, @markj wrote:

In D48034#1095816, @markj wrote:

as suggested, it'd be more natural to cache the value in a local variable instead, assuming that the compiler doesn't recognize that the value is constant and hoist that computation out the loop (which would make this diff even less useful).

Does this diff actually change the generated code? We should avoid these kinds of microoptimizations unless they can be proven to be useful.

I guess the change is either not-noticeable, or non-existent. Perhaps it's better to skip this patch.