Logic Inversion as a Micro-Optimization Tool

A common real-world pattern: a system publishes messages either only when updated or always. The naive implementation usually starts with a flag like only_updated:

bool should_publish(bool only_updated, bool updated)
{
    return (only_updated && updated) || !only_updated;
}

Clang/GCC produce something like:

xor edi, 1
mov eax, edi
or eax, esi
ret

Four instructions.

But if you flip the semantics and introduce a flag that means publish everything, the logic collapses:

bool should_publish(bool everything, bool updated)
{
    return updated || everything;
}

Assembly shrinks by one instruction:

mov eax, esi
or eax, edi
ret

A 33% reduction for an inlined function. In an HFT codebase where this check may execute millions of times per symbol per second, that matters.

When the Trivial Case Dominates

The same inversion pattern shows up in more complex flows. Consider a publisher where:

• subscribed is a global flag meaning “publish all messages.”
• interest[] is a per-message bitmap indicating which updates a client cares about.

The straightforward check:

bool should_publish(bool subscribed, const vector<bool>& interest, size_t index)
{
    return subscribed && interest[index];
}

In production, the overwhelmingly common case is that everything is subscribed. That means the code takes the interest[index] branch constantly, forcing a vector access (which is itself a bit-packed proxy object with non-trivial overhead).

Flip the logic:

bool should_publish(bool everything, const vector<bool>& subscribed, size_t index)
{
    return everything || subscribed[index];
}

Now the hot path is a simple OR with a predictable branch and critically no vector access when everything == true. On a real system this cut 3–5 microseconds per call site under load, purely by avoiding the per-element proxy extraction.

Takeaway

Sometimes the fastest optimization is not a new data structure but flipping the meaning of a flag. If one code path dominates, rewrite your logic so that the dominant path avoids expensive operations entirely. In low-latency systems, “rethink the boolean” is often worth more than any amount of inline assembly.