[Veedrac]

> Then, a bit later, we need to very quickly finish populating the structs.

I am finding it extremely hard to envision a circumstance where this is a bottleneck for anything. Care to clarify the context?

I also find the struct layout really odd; why not just move c?

Your benchmarks are also probably broken; branch predictors use global state so will almost certainly predict fine the way you've used things. You need to repopulate a significantly-sized array each time with randomly chosen values. You can't use the same array because it'll be learnt, and you can't use a short array because it'll be predicted globally.

[dpzmick]

I'll give that benchmark trick a try. Thanks for the feedback.

For some additional context, these structs are packed wire-line protocol structs. In reality the padding bytes are full of other fun details.

[Veedrac]

The question for context is how this became something you want to optimise. It seems almost anything else you do with the values would cost more than the part you tried to optimise.

[dpzmick]

Very little is done with these values in the fast path. The application in question is basically a smart proxy that performs a very minimal amount of formatting. Most of the code in the fast path is pretty linear so I was curious if there were any good way to keep this particular case conditional free.

But, you are right that it probably doesn't matter. The minimal benchmarking I did convinced us that there wouldn't be much of a cost. The code that actually ended up being committed to our project has the branch.