When the computation it replaces is already cheap, or the table wouldn't fit, or the domain is unbounded without acceptable interpolation. If the "expensive" function is actually two or three cheap instructions, a table just wastes memory and, worse, can be slower, a table read may miss the cache and cost more than recomputing, especially on a cached core where the computation stays in registers. If the table would exceed available flash/RAM at the resolution you need, it's out. And there's a maintenance cost: a baked table is only correct while its source parameters are constant, so if those change at runtime the table goes stale and must be rebuilt. The rule is to compare the cost of a memory read (including a possible cache miss) against the cost of the computation, at your actual table size, LUTs win for genuinely expensive functions over bounded domains, and lose for trivial computations or oversized tables.
Data Structures & Algorithms · Interview question
When is a lookup table the wrong choice?
A strong answer
What a weak answer sounds like
You know the answer. Do you know what gets you dinged?
Pro breaks down the answer most candidates actually give to this question — and the specific reason an interviewer marks it down. It’s the difference between sounding correct and sounding senior, on all 472 questions.
From the lesson
Lookup Tables & Precomputation
Trade memory for time: precompute expensive results into a table and replace an O(k) runtime computation with an O(1) array read, the space-time tradeoff that powers DSP, trig, and CRC.