There's a hidden performance trap in Excel's recursive LAMBDAs, and it's not where most users would look. A recent benchmark from a sharp-eyed community member shows that storing an operator in a LET variable *outside* a recursive function, where you'd expect it to be resolved once, can make the whole calculation nearly twice as slow as hardcoding that same operator directly inside the recursion. That's counterintuitive, and it matters for anyone building real-world recursive formulas.
The test is clean: two versions of a factorial-or-sum calculator, identical except that Version A binds the operator (`SUM` or `PRODUCT`) in a `LET` before the recursive `LAMBDA`, while Version B hardcodes `PRODUCT` directly. Running each through a benchmark that averages 5,000 iterations, Version A consistently takes about double the time. This isn't a fluke of the toy example, it's a pattern that will surface in any recursive `LAMBDA` where you try to parameterize an operation this way. The practical takeaway: if performance matters, avoid putting the operator in a `LET` that wraps the recursion. Hardcode it, or find another way to pass it.
What's happening under the hood? Excel's calculation engine apparently doesn't treat the `LET`-bound `op` as a resolved constant inside the recursive call. Each time the `LAMBDA` invokes itself, it re-evaluates the reference to `op`, which in turn re-evaluates the `IF(mode, SUM, PRODUCT)` every recursive step. The `LET` binding is indeed calculated once, but the *reference* to that binding inside the recursive function still carries overhead, perhaps because the engine treats it as a variable lookup in a new evaluation context each recursion. This isn't a bug, but it is a known limitation of how Excel handles name resolution inside iterative or recursive `LAMBDA` calls. The workaround is simple: inline the operator, or restructure the recursion so that the operator is passed as a parameter to the inner `LAMBDA` rather than captured from an outer `LET`.
For spreadsheet builders who rely on recursive LAMBDAs for dynamic arrays, financial models, or data transformations, this is a concrete optimization you can apply today. Don't assume that moving a computation to a `LET` outside the recursion automatically improves performance, test it. In this case, the more explicit, less elegant version is the faster one. That's the kind of practical insight that separates a working formula from a performant one.