Added a simple FIFO cache to defaultMemoize, with a cacheSize option #238

ndbroadbent · 2017-03-29T13:27:20Z

I was using memoize from lodash to create some unbounded caches, which is fine for certain parts of my code. I also know about re-reselect, but that solves a slightly different set of problems.

There are a few cases in my app where I really, really want to have a specific cache size, so that it would store the last 2 or 3 results. One example is where I am using selectors for both old and new props, and comparing the results. Another example is where I have a boolean prop that frequently switches between true and false.

So I've added a cacheSize option to defaultMemoize. If cacheSize is one, then we fall back to the original defaultMemoize code (renamed to memoizeOne.)

If cacheSize is more than one, then we store the args and results in an array. We start appending results to the end of the array and move backwards, until it wraps around to the end and starts overwriting the oldest result. It uses a lastIndex pointer to keep track of the most recent results, so the search always runs from newest to oldest.

I added benchmark tests, and they look fine on my machine. Here's the output after I added a temporary for loop to run them each 5 times:

✓ basic selector cache hit performance (0) (52ms)
✓ selector cacheSize=2 cache hit performance(0) (47ms)
✓ selector cache hit performance for state changes but shallowly equal selector args(0) (197ms)
✓ selector cacheSize=2 cache hit performance for state changes but shallowly equal selector args(0) (222ms)
✓ basic selector cache hit performance (1) (45ms)
✓ selector cacheSize=2 cache hit performance(1) (45ms)
✓ selector cache hit performance for state changes but shallowly equal selector args(1) (440ms)
✓ selector cacheSize=2 cache hit performance for state changes but shallowly equal selector args(1) (225ms)
✓ basic selector cache hit performance (2) (45ms)
✓ selector cacheSize=2 cache hit performance(2) (49ms)
✓ selector cache hit performance for state changes but shallowly equal selector args(2) (209ms)
✓ selector cacheSize=2 cache hit performance for state changes but shallowly equal selector args(2) (226ms)
✓ basic selector cache hit performance (3) (45ms)
✓ selector cacheSize=2 cache hit performance(3) (44ms)
✓ selector cache hit performance for state changes but shallowly equal selector args(3) (213ms)
✓ selector cacheSize=2 cache hit performance for state changes but shallowly equal selector args(3) (221ms)
✓ basic selector cache hit performance (4) (43ms)
✓ selector cacheSize=2 cache hit performance(4) (42ms)
✓ selector cache hit performance for state changes but shallowly equal selector args(4) (201ms)
✓ selector cacheSize=2 cache hit performance for state changes but shallowly equal selector args(4) (218ms)

P.S. I should also mention that I took some inspiration (and tests) from #210. They implemented a LRU cache, but I don't think the performance hit is worth it, and I don't think it was implemented in a very performant way.

coveralls · 2017-03-29T13:31:56Z

Coverage remained the same at 100.0% when pulling 17c8845 on ndbroadbent:memoizeCacheSize into fb8dd53 on reactjs:master.

codecov-io · 2017-03-29T13:32:31Z

Codecov Report

Merging #238 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master   #238   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files           1      1           
  Lines          15     24    +9     
=====================================
+ Hits           15     24    +9

Impacted Files	Coverage Δ
src/index.js	`100% <100%> (ø)`	⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fb8dd53...6721a43. Read the comment docs.

coveralls · 2017-03-29T15:12:39Z