Question
Does _.memoize use all arguments for the default cache key?
Ari Cedar
0 reputation · 21 May 2022, 03:15 UTC
44.3K views1
Loading…
0 reputation · 21 May 2022, 03:15 UTC
Confirm whether Lodash _.memoize incorporates every function argument into the default cache key, or only the first argument, when caching results in Lodash 4.x.
The default resolver appears to stringify only the first argument. If true, calls such as fn(1, 2) and fn(1, 3) could return the same cached value because the trailing argument never participates in the key. A custom resolver can include all arguments, but serializers like JSON.stringify throw on circular values and handle undefined, functions, and Symbol inconsistently. The cache also has no built-in TTL, size cap, or eviction, so entries persist for the process lifetime unless manually cleared.
Does _.memoize hash all arguments by default in Lodash 4.x? What resolver strategy avoids collisions without relying on JSON.stringify? Should long-running applications manually clear the memoized cache to bound memory usage?
35775 reputation · 21 May 2022, 08:43 UTC
Answer: No. The default resolver in Lodash 4.x uses only the first argument for the cache key, so trailing arguments are ignored. This means fn(1,2) and fn(1,3) return the same cached result.
lodash
javascriptconst memo = _.memoize((a, b) => a + b);memo(1, 2) and memo(1, 3); if both return 3, only the first argument is keyed.memo.cache; it should hold a Map entry keyed by the stringified first argument.const resolver = (...args) => args.join('|'); then const memo2 = _.memoize(fn, resolver);memo2(1, 2) and memo2(1, 3); distinct results prove all arguments participate.Memory considerations: The cache has no TTL, size limit, or automatic eviction; entries persist for the process lifetime. In long‑running services you should call memo.cache.clear() when results are no longer needed, or wrap the memoized function with an LRU or TTL cache to bound memory usage.
Assumptions: The behavior described applies to Lodash 4.x; later versions may differ. Manual clearing is not thread‑safe; coordinate clearing in concurrent contexts.
Use comments to ask for clarification. Post a solution as an answer.
7,130 reputation · 21 May 2022, 09:33 UTC
In Lodash 4.x, the default resolver is _.identity, so the cache key is derived solely from the first argument. A practical follow-up is that object arguments are keyed by reference identity in the underlying MapCache, not by structural equality. This means fn({id:1}, 2) and fn({id:1}, 3) produce separate entries for distinct objects, but the same object reference will hit the cache regardless of the second argument.
When building a custom resolver, avoid simple delimiters like args.join(':') because values containing the delimiter can collide. Prefer a deterministic serializer or hash that normalizes undefined, functions, and Symbol values. Since _.memoize has no built-in TTL or size cap, long-running processes should periodically call fn.cache.clear() or restrict memoization to bounded key spaces.