Memoizerific.js
Fast (see benchmarks), small (1k min/gzip), efficient, JavaScript memoization lib to memoize JS functions.
Uses JavaScript's new Map() object for instant lookups, or a performant polyfill if Map is not available - does not do expensive serialization or string manipulation.
Fully supports multiple complex arguments.
Implements least recently used (LRU) caching to maintain only the most recent results.
Made for the browser and nodejs.
Memoization is the process of caching function results so that they can be returned cheaply
without re-execution, when the function 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
Add to your project directly from npm:
npm install memoizerific --save
Or use one of the compiled distributions compatible in any environment (UMD):
Use
var memoizerific = require('memoizerific');
var myExpensiveFunctionMemoized = memoizerific(50)(function(arg1, arg2, arg3) {
});
myExpensiveFunctionMemoized(1, 2, 3);
myExpensiveFunctionMemoized(1, 2, 3);
myExpensiveFunctionMemoized(2, 3, 4);
myExpensiveFunctionMemoized(2, 3, 4);
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);
myExpensiveFunctionMemoized(complexArg1, complexArg2, complexArg3, complexArg4);
Options
There is one option available:
limit:
the max number of results to cache.
memoizerific(limit)(fn);
memoizerific(1)(function(arg1){});
memoizerific(10000)(function(arg1, arg2){});
memoizerific(0)(function(arg1){});
The cache works using LRU logic, purging the least recently used results when the limit is reached.
For example:
var myMemoized = memoizerific(1)(function(arg1) {});
myMemoized(1);
myMemoized(1);
myMemoized(2);
myMemoized(2);
myMemoized(1);
Equality
Arguments are compared using strict equality.
A complex object will only trigger a cache hit if it refers to the exact same object in memory,
not just another object that has similar properties.
For example, the following code won't produce a cache hit even though the objects look the same:
var myMemoized = memoizerific(1)(function(arg1) {});
myMemoized({ a: true });
myMemoized({ a: true });
This is because a new object is being created on each invocation, rather than the same object being passed in.
To fix this, the argument can be saved in a common variable:
var myMemoized = memoizerific(1)(function(arg1) {});
var arg = { a: true };
myMemoized(arg);
myMemoized(arg);
There is an open suggestion to allow for custom comparison functions.
If you think that would be useful please +1 issue #10.
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.
Compared
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:
:heavy_multiplication_x: Memoizejs (@addyosmani)
:heavy_multiplication_x: Memoize-strict (@jshanson7)
:heavy_multiplication_x: Deep-memoize (@rjmk)
:heavy_multiplication_x: Mem (@sindresorhus)
Three libs with reasonable traction seem to meet the basic criteria:
:heavy_check_mark: Memoizee (@medikoo)
:heavy_check_mark: LRU-Memoize (@erikras)
:heavy_check_mark: LRU-Memoize (@neilk)
After some quick testing, however, we found the last library produced incorrect results, leaving only two viable candidates.
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 }}] },
[{ 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 }],
{ z: 'z' },
...
);
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 | Num Args | Approx. Cache Hits (variance) | LRU-Memoize | Memoizee | Memoizerific | % Faster |
---|
10 | 2 | 99% | 19ms | 31ms | 10ms | 90% |
10 | 2 | 62% | 212ms | 319ms | 172ms | 23% |
10 | 2 | 7% | 579ms | 617ms | 518ms | 12% |
| | | | | | |
100 | 2 | 99% | 137ms | 37ms | 20ms | 85% |
100 | 2 | 69% | 696ms | 245ms | 161ms | 52% |
100 | 2 | 10% | 1,057ms | 649ms | 527ms | 23% |
| | | | | | |
500 | 4 | 95% | 476ms | 67ms | 62ms | 8% |
500 | 4 | 36% | 2,642ms | 703ms | 594ms | 18% |
500 | 4 | 11% | 3,619ms | 880ms | 725ms | 21% |
| | | | | | |
1000 | 8 | 95% | 1,009ms | 52ms | 65ms | 25% |
1000 | 8 | 14% | 10,477ms | 659ms | 635ms | 4% |
1000 | 8 | 1% | 6,943ms | 1,501ms | 1,466ms | 2% |
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 well with few arguments and lots of cache hits, it quickly degraded 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 others, like memoizing in a loop,
or recursively, it might be. Importantly though, it degraded gracefully, and remained within
sub 1s levels almost all the time. Memoizee is acceptable for production use.
Memoizerific was fastest in all tests except one. It was built for production with
complex real-world use in mind.
License
Released under an MIT license.
Related
- 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.
Other
Like it? Star It