Memoizerific.js

Fast (see benchmarks), small (1k min/gzip), efficient, JavaScript memoization lib to memoize JS functions. Fully supports multiple complex object arguments. Implements LRU caching (least recently used caching) to maintain only the most recent results.

Made for the browser and nodejs. Uses JavaScript Map() for instant object lookups, or a performant polyfill if Map is not available - does not do serialization or string manipulation.

Memoization is the process of caching function results, so that they can be returned cheaply without re-running the function when it is called again with the same arguments. This is especially useful with the rise of redux-philosophy, and the push to calculate derived data on the fly to maintain minimal state.

Install

npm install memoizerific --save

Or use one of the compiled distributions compatible in any environment (umd):

• memoizerific.js
• memoizerific.min.js (minified)
• memoizerific.min.gzip.js (minified + gzipped)

Use

var memoizerific = require('memoizerific');

var myExpensiveFunctionMemoized = memoizerific(50)(function(arg1, arg2, arg3) {
    // so many long expensive calls in here
});

myExpensiveFunctionMemoized(1, 2, 3); // that took looooong to process
myExpensiveFunctionMemoized(1, 2, 3); // wow, that one was instant!
myExpensiveFunctionMemoized(2, 3, 4); // expensive again :(
myExpensiveFunctionMemoized(2, 3, 4); // woah, this one was dirt cheap, I'll take 2!

Or with complex arguments:

var complexArg1 = { a: { b: { c: 99 }}},
    complexArg2 = [{ z: 1}, { q: [{ x: 3 }]}],
    complexArg3 = new Map([['d', 55],['e', 66]]),
    complexArg4 = new Set();

myExpensiveFunctionMemoized(complexArg1, complexArg2, complexArg3, complexArg4); // slow
myExpensiveFunctionMemoized(complexArg1, complexArg2, complexArg3, complexArg4); // instant!

Options

There is one option available:

limit: the max number of results to cache.

memoizerific(limit)(fn);

memoizerific(1)(function(){}); // memoize 1 result
memoizerific(10000)(function(){}); // memoize 10,000 results
memoizerific(0)(function(){}); // memoize infinity results (not recommended)

The cache works using LRU logic, purging the least recently used results when the limit is reached. For example:

// memoize 1 result
var myMemoized = memoizerific(1)(function(arg1, arg2, arg3, arg4) {});

myMemoized(1, 2, 3, 'a'); // function runs, result is cached
myMemoized(1, 2, 3, 'a'); // cached result is returned
myMemoized(1, 2, 3, 'X'); // function runs again, new result is cached, old cached result is purged
myMemoized(1, 2, 3, 'X'); // new cached result is returned
myMemoized(1, 2, 3, 'a'); // function runs again...

Internals

The internals of the memoized function are available for introspection. They should not be manipulated directly, but can be useful to read. The following properties are available:

memoizedFn.limit       : The cache limit that was passed in. This will never change.
memoizedFn.wasMemoized : Returns true if the last invocation was a cache hit, otherwise false.
memoizedFn.cache       : The cache object that stores all the memoized results.
memoizedFn.lru         : The lru object that stores the most recent arguments called.

Comparison

There are many memoization libs available for JavaScript. Some of them have specialized use-cases, such as memoizing file-system access, or server async requests. While others, such as this one, tackle the more general case of memoizing standard synchronous functions. Following are the minimum criteria I look for in a production-worthy memoization solution:

• Support for multiple arguments: One argument memoizers start to fall short quickly when solving real problems.
• Support for complex arguments: Including large arrays, complex objects, arrays-within-objects, objects-within-arrays, etc. (not just primitives like strings or numbers).
• Controlled cache: A cache that grows unimpeded will quickly become a memory leak and source of bugs.
• Consistent performance profile: Many libs perform well within certain parameters, but start to fail wildly in others, usually when a large cache is chosen, or many arguments are used. It is important that performance degrades predictably and linearly as the environment becomes less favorable to avoid nasty surprises.

Using this list, we can narrow down the field of possible candidates quite a bit. The popular lodash memoize, for example, only supports one argument out of the box and has no cache control. Others support multiple complex arguments, but do not offer mechanisms to manage the cache-size:

• ✖️ Memoizejs (@addyosmani)

• ✖️ Memoize-strict (@jshanson7)

• ✖️ Deep-memoize (@rjmk)

• ✖️ Mem (@sindresorhus)

Three libs with reasonable traction seem to meet the basic criteria:

• Memoizee (@medikoo)
• LRU-Memoize (@erikras)
• LRU-Memoize (@neilk)

After some quick testing, however, we found the library by @neilk to be producing incorrect results, leaving only two viable candidates.

Time to test performance.

Benchmarks

This library is intended for real-world use-cases, and is therefore benchmarked using large, complex, real-world data. There are enough fibonacci solvers out there. Example arguments look like this:

myMemoized(
    { a: 1, b: [{ c: 2, d: { e: 3 }}] }, // 1st argument
    [{ x: 'x', q: 'q', }, { b: 8, c: 9 }, { b: 2, c: [{x: 5, y: 3}, {x: 2, y: 7}] }, { b: 8, c: 9 }, { b: 8, c: 9 }], // 2nd argument
    { z: 'z' }, // 3rd argument
    ... // 4th, 5th... argument
);

We generated sets of thousands of random argument combinations of varying variance (to increase and decrease cache hits and misses) and fed them to each library.

Data

Following is data from 5000 iterations of each test on firefox 44:

Cache Size                    : The maximum number of results to cache.
Num Args                      : The number of arguments the memoized function accepts, ex. fn(arg1, arg2, arg3) is 3.
Approx. Cache Hits (variance) : How varied the passed in arguments are. If the exact same arguments are always used, the cache would be hit 100% of the time. If the same arguments are never used, the cache would be hit 0% of the time.
% Faster                      : How much faster the 1st best performer was from the 2nd best performer (not against the worst performer).

Results

The results from the tests are interesting. While LRU-Memoize performed quite well with few arguments and lots of cache hits, it quickly started to fall apart as the environment became more challenging. At 4+ arguments, it was 5x-10x-20x slower than the other contenders, and began to hit severe performance issues that could potentially cause real-world problems. I would not recommend it for heavy production use.

Memoizee came in a solid second place, around 31% less performant than Memoizerific. In most scenarios this will not be very noticeable. In other, especially demanding ones, such as memoizing in a loop, or through a long recursion chain, it might be. Importantly though, it degraded very gracefully, and remained within sub 1s levels almost all the time. Memoizee is a sturdy, well-built library that I would recommend for production use.

Memoizerific was the performance winner. It is built with complex real-world use in mind. I would, of course, recommend it for serious production use.

License

Released under an MIT license.

Other Libs

• Map or Similar: A JavaScript (JS) Map or Similar object polyfill if Map is not available.
• Multi Key Cache: A JavaScript (JS) cache that can have multiple complex values as keys.