How To Make Your Code Faster with Boolean Algebra

Why Every Programmer Should Learn Boolean Algebra

A single Boolean expression can be the difference between code that returns in milliseconds and code that takes seconds. Look at these two conditions, they have the same functionality but one much faster.

if (expensiveCheck() && isLoggedIn())

if (isLoggedIn() && expensiveCheck())

Boolean Algebra Isn't Just for Hardware

Most programmers never learn the basics of Boolean algebra. That's a mistake, because even in high-level programming languages, optimizations are still available using these concepts. Every if, every while, every SQL WHERE clause, every search filter your product runs is a Boolean expression evaluating true or false against real data.

The compiler doesn't know your intent, it only knows the expression you wrote. Two logically equivalent expressions can compile to wildly different amounts of runtime work, and the rules for which is which are exactly the rules of Boolean algebra: short-circuit evaluation, De Morgan's laws, distribution, factoring. You already used one of them in the last section without naming it.

Eliminate Unnecessary Work

Short-circuit evaluation means && stops at the first false, and || stops at the first true. Whatever comes after that point never executes. Since you would rather short circuit from the less expensive function, the order matters.

if (expensiveRegex(text) && isValidUser)

Try it: order these from cheapest to most expensive

Use the arrows to reorder. These four checks are meant to be chained with && , and any one of them could be the one that fails. The cost numbers are illustrative, not a benchmark, chosen to be roughly the right order of magnitude relative to each other.

Simplify Your Conditions

The second rule isn't about order, it's about redundant structure. Boolean algebra lets you factor a condition the same way you'd factor an equation, and the factored version usually costs less to evaluate and is easier for the next person to read.

if (
    (isAdmin && canEdit) ||
    (isAdmin && canDelete)
)

Order Matters at Scale

Say a permission check costs meaningfully more than a login check, and a request comes in from a user who isn't logged in.

if (
    expensivePermissionCheck() &&
    isLoggedIn()
)

if (
    isLoggedIn() &&
    expensivePermissionCheck()
)

Real Consequences

Database queries

WHERE indexed_col = ? AND slow_col LIKE ? versus the same clauses reversed can be the difference between a query that hits an index and one that scans every row before it even gets to the cheap comparison. Query planners are smart, but they're not always smart enough to reorder around an expensive function call.

Search

Cheap filters (category, price range, in-stock) should run before expensive ones (semantic similarity, fuzzy matching). Narrow the candidate set with boolean logic first, then spend the expensive computation only on what's left.

Game development

Axis-aligned bounding box checks are nearly free, compared to full physics collision resolution which can be expensive. Every collision system checks the cheap box first and only runs the expensive math for objects that were already close enough to plausibly collide. These are the kinds of optimizations which can give huge returns in performance from something as simple as changing the order of an if statement or prioritizing less expensive tasks.

Practice Challenge

if (
    expensiveValidation(data) &&
    userExists &&
    hasPermission &&
    hasSubscription
)

Quick Recap Quiz

Key Takeaways

- Put cheap conditions first, expensive ones last. Short-circuiting does the rest.

- Factor repeated logic instead of duplicating it. Less work, and one source of truth.

- Remove evaluations you don't need before you optimize the ones you do.

- You can even do a simpler check before doing an expensive one to sift unlikely candidates, kind of like what we discussed with the hitboxes earlier.