Giter VIP home page Giter VIP logo

memoizee's Introduction

*nix build status Windows build status Transpilation status npm version

Memoizee

Complete memoize/cache solution for JavaScript

Originally derived from es5-ext package.

Memoization is best technique to save on memory or CPU cycles when we deal with repeated operations. For detailed insight see: http://en.wikipedia.org/wiki/Memoization

Features

Installation

In your project path — note the two e's in memoizee:

$ npm install memoizee
# or with yarn
$ yarn add memoizee

memoize name was already taken, therefore project is published as memoizee on NPM.

To port it to Browser or any other (non CJS) environment, use your favorite CJS bundler. No favorite yet? Try: Browserify, Webmake or Webpack

Usage

var memoize = require("memoizee");

var fn = function(one, two, three) {
	/* ... */
};

memoized = memoize(fn);

memoized("foo", 3, "bar");
memoized("foo", 3, "bar"); // Cache hit

Note: Invocations that throw exceptions are not cached.

Configuration

All below options can be applied in any combination

Arguments length

By default fixed number of arguments that function take is assumed (it's read from function's length property) this can be overridden:

memoized = memoize(fn, { length: 2 });

memoized("foo"); // Assumed: 'foo', undefined
memoized("foo", undefined); // Cache hit

memoized("foo", 3, {}); // Third argument is ignored (but passed to underlying function)
memoized("foo", 3, 13); // Cache hit

Note: Parameters predefined with default values (ES2015+ feature) are not reflected in function's length, therefore if you want to memoize them as well, you need to tweak length setting accordingly

Dynamic length behavior can be forced by setting length to false, that means memoize will work with any number of arguments.

memoized = memoize(fn, { length: false });

memoized("foo");
memoized("foo"); // Cache hit
memoized("foo", undefined);
memoized("foo", undefined); // Cache hit

memoized("foo", 3, {});
memoized("foo", 3, 13);
memoized("foo", 3, 13); // Cache hit

Primitive mode

If we work with large result sets, or memoize hot functions, default mode may not perform as fast as we expect. In that case it's good to run memoization in primitive mode. To provide fast access, results are saved in hash instead of an array. Generated hash ids are result of arguments to string conversion. Mind that this mode will work correctly only if stringified arguments produce unique strings.

memoized = memoize(fn, { primitive: true });

memoized("/path/one");
memoized("/path/one"); // Cache hit

Cache id resolution (normalization)

By default cache id for given call is resolved either by:

  • Direct Comparison of values passed in arguments as they are. In such case two different objects, even if their characteristics is exactly same (e.g. var a = { foo: 'bar' }, b = { foo: 'bar' }) will be treated as two different values.
  • Comparison of stringified values of given arguments (primitive mode), which serves well, when arguments are expected to be primitive values, or objects that stringify naturally do unique values (e.g. arrays)

Still above two methods do not serve all cases, e.g. if we want to memoize function where arguments are hash objects which we do not want to compare by instance but by its content.

Writing custom cache id normalizers

There's a normalizer option through which we can pass custom cache id normalization function.

Memoizing on dictionary (object hash) arguments)

if we want to memoize a function where argument is a hash object which we do not want to compare by instance but by its content, then we can achieve it as following:

var mfn = memoize(
	function(hash) {
		// body of memoized function
	},
	{
		normalizer: function(args) {
			// args is arguments object as accessible in memoized function
			return JSON.stringify(args[0]);
		}
	}
);

mfn({ foo: "bar" });
mfn({ foo: "bar" }); // Cache hit

If additionally we want to ensure that our logic works well with different order of properties, we need to imply an additional sorting, e.g.

const deepSortedEntries = object =>
	Object.entries(object)
		.map(([key, value]) => {
			if (value && typeof value === "object") return [key, deepSortedEntries(value)];
			return [key, value];
		})
		.sort();

var mfn = memoize(
	function(hash) {
		// body of memoized function
	},
	{
		normalizer: function(args) {
			// args is arguments object as accessible in memoized function
			return JSON.stringify(deepSortedEntries(args[0]));
		}
	}
);

mfn({ foo: "bar", bar: "foo" });
mfn({ bar: "foo", foo: "bar" }); // Cache hit

Argument resolvers

When we're expecting arguments of certain type it's good to coerce them before doing memoization. We can do that by passing additional resolvers array:

memoized = memoize(fn, { length: 2, resolvers: [String, Boolean] });

memoized(12, [1, 2, 3].length);
memoized("12", true); // Cache hit
memoized(
	{
		toString: function() {
			return "12";
		}
	},
	{}
); // Cache hit

Note. If your arguments are collections (arrays or hashes) that you want to memoize by content (not by self objects), you need to cast them to strings, for it's best to just use primitive mode. Arrays have standard string representation and work with primitive mode out of a box, for hashes you need to define toString method, that will produce unique string descriptions, or rely on JSON.stringify.

Similarly if you want to memoize functions by their code representation not by their objects, you should use primitive mode.

Memoizing asynchronous functions

Promise returning functions

With promise option we indicate that we memoize a function that returns promise.

The difference from natural behavior is that in case when promise was rejected with exception, the result is immediately removed from memoize cache, and not kept as further reusable result.

var afn = function(a, b) {
	return new Promise(function(res) {
		res(a + b);
	});
};
memoized = memoize(afn, { promise: true });

memoized(3, 7);
memoized(3, 7); // Cache hit
Important notice on internal promises handling

Default handling stands purely on then which has side-effect of muting eventual unhandled rejection notifications. Alternatively we can other (explained below), by stating with promise option desired mode:

memoized = memoize(afn, { promise: "done:finally" });

Supported modes

  • then (default). Values are resolved purely by passing callbacks to promise.then. Side effect is that eventual unhandled rejection on given promise come with no logged warning!, and that to avoid implied error swallowing both states are resolved tick after callbacks were invoked

  • done Values are resolved purely by passing callback to done method. Side effect is that eventual unhandled rejection on given promise come with no logged warning!.

  • done:finally The only method that may work with no side-effects assuming that promise implementaion does not throw unconditionally if no onFailure callback was passed to done, and promise error was handled by other consumer (this is not commonly implemented done behavior). Otherwise side-effect is that exception is thrown on promise rejection (highly not recommended)

Node.js callback style functions

With async option we indicate that we memoize asynchronous (Node.js style) function Operations that result with an error are not cached.

afn = function(a, b, cb) {
	setTimeout(function() {
		cb(null, a + b);
	}, 200);
};
memoized = memoize(afn, { async: true });

memoized(3, 7, function(err, res) {
	memoized(3, 7, function(err, res) {
		// Cache hit
	});
});

memoized(3, 7, function(err, res) {
	// Cache hit
});

Memoizing methods

When we are defining a prototype, we may want to define a method that will memoize it's results in relation to each instance. A basic way to obtain that would be:

var Foo = function() {
	this.bar = memoize(this.bar.bind(this), { someOption: true });
	// ... constructor logic
};
Foo.prototype.bar = function() {
	// ... method logic
};

There's a lazy methods descriptor generator provided:

var d = require("d");
var memoizeMethods = require("memoizee/methods");

var Foo = function() {
	// ... constructor logic
};
Object.defineProperties(
	Foo.prototype,
	memoizeMethods({
		bar: d(
			function() {
				// ... method logic
			},
			{ someOption: true }
		)
	})
);

WeakMap based configurations

In this case memoization cache is not bound to memoized function (which we may want to keep forever), but to objects for which given results were generated.

This mode works only for functions of which first argument is expected to be an object.
It can be combined with other options mentioned across documentation. However due to WeakMap specificity global clear is not possible.

var memoize = require("memoizee/weak");

var memoized = memoize(function(obj) {
	return Object.keys(obj);
});

var obj = { foo: true, bar: false };
memoized(obj);
memoized(obj); // Cache hit

Cache handling

Manual clean up:

Delete data for particular call.

memoized.delete("foo", true);

Arguments passed to delete are treated with same rules as input arguments passed to function

Clear all cached data:

memoized.clear();
Expire cache after given period of time

With maxAge option we can ensure that cache for given call is cleared after predefined period of time (in milliseconds)

memoized = memoize(fn, { maxAge: 1000 }); // 1 second

memoized("foo", 3);
memoized("foo", 3); // Cache hit
setTimeout(function() {
	memoized("foo", 3); // No longer in cache, re-executed
	memoized("foo", 3); // Cache hit
}, 2000);

Additionally we may ask to pre-fetch in a background a value that is about to expire. Pre-fetch is invoked only if value is accessed close to its expiry date. By default it needs to be within at least 33% of maxAge timespan before expire:

memoized = memoize(fn, { maxAge: 1000, preFetch: true }); // Defaults to 0.33

memoized("foo", 3);
memoized("foo", 3); // Cache hit

setTimeout(function() {
	memoized("foo", 3); // Cache hit
}, 500);

setTimeout(function() {
	memoized("foo", 3); // Cache hit, silently pre-fetched in next tick
}, 800);

setTimeout(function() {
	memoized("foo", 3); // Cache hit
}, 1300);

Pre-fetch timespan can be customized:

memoized = memoize(fn, { maxAge: 1000, preFetch: 0.6 });

memoized("foo", 3);
memoized("foo", 3); // Cache hit

setTimeout(function() {
	memoized("foo", 3); // Cache hit, silently pre-fetched in next tick
}, 500);

setTimeout(function() {
	memoized("foo", 3); // Cache hit
}, 1300);

Thanks @puzrin for helpful suggestions concerning this functionality

Reference counter

We can track number of references returned from cache, and manually delete them. When the last reference is cleared, the cache is purged automatically:

memoized = memoize(fn, { refCounter: true });

memoized("foo", 3); // refs: 1
memoized("foo", 3); // Cache hit, refs: 2
memoized("foo", 3); // Cache hit, refs: 3
memoized.deleteRef("foo", 3); // refs: 2
memoized.deleteRef("foo", 3); // refs: 1
memoized.deleteRef("foo", 3); // refs: 0, Cache purged for 'foo', 3
memoized("foo", 3); // Re-executed, refs: 1
Limiting cache size

With max option you can limit cache size, it's backed with LRU algorithm, provided by low-level lru-queue utility.

The size relates purely to count of results we want to keep in cache, it doesn't relate to memory cost associated with cache value (but such feature is likely to be introduced with next version of memoizee).

memoized = memoize(fn, { max: 2 });

memoized("foo", 3);
memoized("bar", 7);
memoized("foo", 3); // Cache hit
memoized("bar", 7); // Cache hit
memoized("lorem", 11); // Cache cleared for 'foo', 3
memoized("bar", 7); // Cache hit
memoized("foo", 3); // Re-executed, Cache cleared for 'lorem', 11
memoized("lorem", 11); // Re-executed, Cache cleared for 'bar', 7
memoized("foo", 3); // Cache hit
memoized("bar", 7); // Re-executed, Cache cleared for 'lorem', 11
Registering dispose callback

You can register a callback to be called on each value removed from the cache:

memoized = memoize(fn, {
	dispose: function(value) {
		/*…*/
	}
});

var foo3 = memoized("foo", 3);
var bar7 = memoized("bar", 7);
memoized.clear("foo", 3); // Dispose called with foo3 value
memoized.clear("bar", 7); // Dispose called with bar7 value

Benchmarks

Simple benchmark tests can be found in benchmark folder. Currently it's just plain simple calculation of fibonacci sequences. To run it you need to install other test candidates:

$ npm install underscore lodash lru-cache secondary-cache

Example output taken under Node v0.10.35 on 2011 MBP Pro:

Fibonacci 3000 x10:

1:    15ms  Memoizee (primitive mode)
2:    15ms  Underscore
3:    18ms  lru-cache                 LRU (max: 1000)
4:    21ms  secondary-cache           LRU (max: 1000)
5:    37ms  Lo-dash
6:    62ms  Memoizee (primitive mode) LRU (max: 1000)
7:   163ms  Memoizee (object mode)    LRU (max: 1000)
8:   195ms  Memoizee (object mode)

Profiling & Statistics

If you want to make sure how much you benefit from memoization or just check if memoization works as expected, loading profile module will give access to all valuable information.

Module needs to be imported before any memoization (that we want to track) is configured. Mind also that running profile module affects performance, it's best not to use it in production environment

var memProfile = require('memoizee/profile');
...
...
memoize(fn);
...
memoize(fn, { profileName: 'Some Function' })
...
memoize(fn, { profileName: 'Another Function' })

Access statistics at any time:

memProfile.statistics; // Statistics accessible for programmatic use
console.log(memProfile.log()); // Output statistics data in readable form

Example console output:

------------------------------------------------------------
Memoize statistics:

 Init  Cache  %Cache  Source location
11604  35682   75.46  (all)
 2112  19901   90.41  Some Function, at /Users/medikoo/Projects/_packages/next/lib/fs/is-ignored.js:276:12
 2108   9087   81.17  Another Function, at /Users/medikoo/Projects/_packages/next/lib/fs/is-ignored.js:293:10
 6687   2772   29.31  at /Users/medikoo/Projects/_packages/next/lib/fs/watch.js:125:9
  697   3922   84.91  at /Users/medikoo/Projects/_packages/next/lib/fs/is-ignored.js:277:15
------------------------------------------------------------
  • Init – Initial hits
  • Cache – Cache hits
  • %Cache – What's the percentage of cache hits (of all function calls)
  • Source location – Where in the source code given memoization was initialized

Tests

$ npm test

Project cross-browser compatibility to be supported by:

Security contact information

To report a security vulnerability, please use the Tidelift security contact. Tidelift will coordinate the fix and disclosure.


Get professional support for d with a Tidelift subscription
Tidelift helps make open source sustainable for maintainers while giving companies
assurances about security, maintenance, and licensing for their dependencies.

Contributors

  • @puzrin (Vitaly Puzrin)
    • Proposal and help with coining right pre-fetch logic for maxAge variant

memoizee's People

Contributors

amilajack avatar andrew--r avatar epayet avatar ericthemagician avatar hem-brahmbhatt avatar johannchopin avatar jonschlinkert avatar juanpicado avatar kirill89 avatar medikoo avatar newyork-anthonyng avatar page- avatar scottbedard avatar thgreasi avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

memoizee's Issues

memoized.delete() doesn't work for async

I have the following functions:

self.loadUrlText = function(url, callback) {
    d3.text(url, undefined, function(error, result) {
        callback(error, result);
    });
}

self.loadUrlPage = memoize(self.loadUrlText, {
    async: true,
    max: 100,
    maxAge: 1000 * 60 * 60
});

However after I call:

if (noCache) {
    alert('Uncache: ' + url);
    self.loadUrlPage.delete(url);
}

the memoized function still keeps returning the cached value without calling the underlying function.

Memoize simultaneous calls to single call

When I have a slow running async function memoized and it's called multiple times before the first result is remembered, it will actually call the actual function multiple times. Would be nice if it remembered that the function is being resolved and to not try to resolve it, instead if could simply get its callback run when the original/first call is resolved... let me know if I made it clear, I had a hard time describing it. :)

fix README

fix README

require('memoizee');

to

require('memoize');

whatever, project name should be the same.

Caches big enough to store data in file system

For example, I'd like to make a function that downloads files from the internet, but if they were already downloaded, gets them from the cache on hdd. That's certainly a kind of memoization: persistent, with hdd cache. Shouldn't it be in memoize?

TypeError: Cannot read property 'length' of undefined

TypeError: Cannot read property 'length' of undefined
    at Function.self (/home/app/node_modules/memoizee/ext/async.js:88:67)

Seems similar to #13 except I'm not sure of what exact scenario triggers this.

In ext/async.js, It seems that cb is assumed to either be a function or an Array of functions from the waiting[id] property. However, somehow, occasionally waiting[id] seems to be undefined when this code runs causing cb to also be undefined, which throws the error when cb.length is called when the 'setasync' method is emitted.

Is there possibly some race condition going on here where once callback clears the waiting queue before another unexpectedly tries to run? Can you think of any possible reasons why cb could be undefined?

Observed on v0.3.5 and previous versions.

Hangs NodeJS on shutdown when using maxAge.

NodeJs 0.10.33

When I shut down the server it hangs up to the maxAge time before the process exits. Suggests the cache expiry timer is keeping the event loop going.

If I clear the cache explicitly the process exits immediately, but this means I need to track all memoized functions.

Resolver result is incorrectly passed to function

Since the 0.3.10 update my memoized function incorrectly returns the result of the resolver instead of passing on the input.

My simplified code.

const memoized = (func) =>
  memoizee(func, {
    resolvers: [(params) => JSON.stringify(params)],
  })

function queryResource(params) {
  console.log(typeof params, params)
}

const query = memoized(queryResource)

query({ limit: 10 })

Expected

object { limit: 10 } 

Actual

string "{ limit: 10 }"

I understand from the commits that a bug in the resolvers has been fixed. Should I update the implementation of my resolver or would this be a regression?

What's the unit for maxAge?

The examples say maxAge: 1000 for memoized functions that timeout. Is that milliseconds or seconds?

(This module looks super-useful. Thanks for writing it!)

Better documentation for resolvers?

I'm a huge fan of the built-in stats and cache management tools that memoizee offers, but right now I'm totally puzzled by how I'm supposed to use the resolver functionality.

Lodash and Underscore resolvers are very straight forward. For those, you provide a function which returns the key used for the cache map.

Like this:
const memoizedFunction = _.memoize(nonMemoizedFunction, (anObject, aBool) => anObject.id + aBool.toString() );

Memoizee's resolver functionality, however, is a lot less clear.

To me, it's not apparent from the documentation how to craft a resolver function and it seems that memoizee focuses on argument type as opposed to allowing for arbitrary key construction.

Is it possible to memoize based on a given object's property instead of attempting to serialize the entire object? What about combining that with a second parameter?

For example, given foo(anObject, aBool), I'd like my memoization key to be anObject.id + bool.

Given how important resolvers are to a memoization library functioning as intended, I think the documentation would really benefit from being beefed up with useful examples as opposed to trivial ones.

Am I missing something about memoization?

I wrote a short snippet of test code, to see memoize really increases performance or not, this runs in Firefox 33.0

function timeoize () {
    function translate(value, leftMin, leftMax, rightMin, rightMax) {
        var leftSpan = leftMax - leftMin;
        var rightSpan = rightMax - rightMin;

        var scaled = (value - leftMin) / leftSpan;
        return rightMin + scaled * rightSpan;
    }

    var memoTranslate = memoize(translate);

    console.time("clean translate");
    for (var i = 0; i < 100000; i++) {
        translate(i, 0, 10, 10, 100);
    }
    console.timeEnd("clean translate");

    console.time("Non-memoized translate");
    for (var i = 0; i < 100000; i++) {
        memoTranslate(i, 0, 10, 10, 100);
    }
    console.timeEnd("Non-memoized translate");

    console.time("memoized translate");
    for (var i = 0; i < 100000; i++) {
        memoTranslate(i, 0, 10, 10, 100);
    }
    console.timeEnd("memoized translate");
}

The output of running timeoize() is

Firefox 33.0
clean translate: timer started
clean translate: 1.64ms
Non-memoized translate: timer started
Non-memoized translate: 22800.4ms
memoized translate: timer started
memoized translate: 9605.07ms

Chrome Version 38.0.2125.122 (64-bit):
clean translate: 14.276ms
Non-memoized translate: 96632.095ms <-- that's well over a minute
memoized translate: 29126.279ms

Why is the memoized version of my translate function that much slower? Instead of improving performance, this memoization converts a piece of code that took less than 2 ms to run to 22 seconds for the non-cached version of the function, and just under 10 seconds for the cached version.

Am I missing something really obvious here?

memoized values open to corruption, clone option could be useful?

It seems the library returns the direct object in the cache. This opens the cache to possible corruption by client code.

A made up example:

memoized('id1', function(err, res) {
  res.foo = 'bar';
});

and in another place..

memoized('id1', function(err, res) {
  if(!res.foo) {
    // do something
  }
});

context 1 corrupted the cached value and could effect context 2.

It would be cool if we could specifically state that we want cached values cloned in return.
For example something like:

var memoized = memoize(myfn, { length: 1, async: true, maxAge: 5000, clone: true });

I can try and do a PR, but I am not sure where specifically the code should go? Only in plain.js at the final return statement? Or in some other places as well? I imagine deep cloning would be preferred, perhaps using clone.

Feature request: expose core

So this memoization module is based on an LRU + expiry cache unit, right?
It'd be very helpful if we could use this unit directly, without the function decorator...

Cache persistence

I use memoize in a Node Web Service application.

  1. When I shutdown the service, can I rescue the cache created before the shutdown?
  2. The same scenario when I move my service to other server.
    Can I save the cache in disk and then when the service begin assign to the memoize object again?
    Thanks

v0.3.9 release

Would it be possible to get a 0.3.9 release? Anything I could do to help make that happen?

In particular, this commit would be very helpful to me.

I'm using Karma and experienced a bug with the stack trace below. The issue is fixed when I change Karma's memoize dependency from this:

"memoizee": "^0.3.8",

to this:

"memoizee": "[email protected]:medikoo/memoize.git",

Once there is a new memoizee release I'll be able to submit a simple PR to Karma that fixes the issue by updating the dependency from 0.3.8 to 0.3.9.

Thanks! 😸

The stack trace I mentioned above:

/vagrant/core/ux/node_modules/karma/node_modules/memoizee/lib/weak.js:58
                clear: d(map.clear.bind(map))
                                  ^
TypeError: Cannot read property 'bind' of undefined
    at /vagrant/core/ux/node_modules/karma/node_modules/memoizee/lib/weak.js:58:23
    at createErrorFormatter (/vagrant/core/ux/node_modules/karma/lib/reporter.js:32:30)
    at createReporters (/vagrant/core/ux/node_modules/karma/lib/reporter.js:75:24)
    at Array.invoke (/vagrant/core/ux/node_modules/karma/node_modules/di/lib/injector.js:75:15)
    at [object Object].get (/vagrant/core/ux/node_modules/karma/node_modules/di/lib/injector.js:48:43)
    at get (/vagrant/core/ux/node_modules/karma/node_modules/di/lib/injector.js:54:19)
    at /vagrant/core/ux/node_modules/karma/node_modules/di/lib/injector.js:71:14
    at Array.map (native)
    at [object Object].invoke (/vagrant/core/ux/node_modules/karma/node_modules/di/lib/injector.js:70:31)
    at createWebServer (/vagrant/core/ux/node_modules/karma/lib/web-server.js:51:19)
    at Array.invoke (/vagrant/core/ux/node_modules/karma/node_modules/di/lib/injector.js:75:15)
    at get (/vagrant/core/ux/node_modules/karma/node_modules/di/lib/injector.js:48:43)
    at /vagrant/core/ux/node_modules/karma/node_modules/di/lib/injector.js:71:14
    at Array.map (native)
    at [object Object].invoke (/vagrant/core/ux/node_modules/karma/node_modules/di/lib/injector.js:70:31)
    at [object Object].Server.start (/vagrant/core/ux/node_modules/karma/lib/server.js:92:18)

Error: Circular invocation

Sometimes I'm getting Circular invocation exceptions. What exactly does this mean and how can I fix it?

Chaining off of cached Promise causes cached value to be modified

I just recently found out that when using this library to memoize a function that returns a promise that if you chain a .then off the cached value and then return anything besides the original value (or don't return anything at all) then you will end up modifying the cached value to whatever you returned (or undefined if you don't return anything).

Example:

'use strict';

var memoize = require('memoizee'),
    promise = require('bluebird');

var returnPromisifiedArray = function ( number ) {
    return new promise(function (resolve, reject) {
        resolve([{val : number}]);
    });
}

var returnTestArray = function ( numberInArray ) {
    console.log('Cache miss! Called with: ' + numberInArray);
    return returnPromisifiedArray(numberInArray);
};

var returnTestArrayMemoized = memoize(returnTestArray, {primitive: true, max: 1000});

var runTest = function () {
    return returnTestArrayMemoized(1)
        .then(function (value) {
            console.log(value);
            value = value.map(function(item) {
                item.badVal = 'fail';
                return item;
            });
            return value;
        }).catch(function (err) {
            console.log('unexpected error');
        });
};

runTest(); // Retrieves [ {a : 'b'} ] from the cache (expected value)
runTest(); // Retrieves [ {a : 'b', badVal : 'fail'} ] from the cache (not the expected value)

This example appears to be hitting line 78 and 86 in configure-map.js which is setting the cache to have the original return value and then later returns it, which potentially allows for modifications to be made to the cached value.

Not sure if you consider this part of the scope of #35 or not, but I figured it couldn't hurt to log it here in case other people also run into this.

TypeError in async.js after calling clear()

@medikoo since upgrading to 0.3.3 from 0.2.x, I am experiencing several TypeError's in async.js after clearing the cache. The errors are basically two and I was able to consistently reproduce the problem.

The following code memoizes an async function asyncfn and clears the cache between the two calls:

var memoize = require("memoizee");

function asyncfn (val, cb) {
    setTimeout(function () {
        cb(null, val);
    }, 0);
}

var asyncmem = memoize(asyncfn, {
    async: true
});

function done(err, val) {
    console.log(val);
}

asyncmem(1, done);
asyncmem.clear();
asyncmem(2, done); // TypeError is thrown after this call

It will always break with 'TypeError: Cannot read property \'length\' of undefined', ' at .../memoizee/ext/async.js:88:67 after the second asyncmem call.

Now, if asyncfn returns an error to its callback by changing cb(null, val); in line 5 by cb(new Error(), val);, it will always break with 'TypeError: Cannot call method \'forEach\' of undefined', ' at .../memoizee/ext/async.js:94:8.

Both errors are related to calling clear() in between two calls. Can you please take a look at this issue and advice how it can be solved?

Thanks!!!

async primitive single-argument null kills node

Tested on 0.3.4

var memoize = require('memoizee');

var f = memoize(function f(id, cb) {
    console.log("I got " + id);
    cb(null, {});
},{
    async: true,
    primitive: true
});

f(null, function(err, res) {
    if (err) console.error(err);
    console.log(res);
});

For that matter, the lack of a normalizer for single-argument primitive mode makes it quirky on anything that's not guaranteed to be a string.

Latest version not published on NPM?

I tried using the WeakMap functionality which was recently added, but the weakMap module was not there, so I got the standard "cannot find module" error from node when I tried to require it:

var memoize = require('memoizee/weak');
module.js:340
    throw err;
          ^
Error: Cannot find module 'memoizee/weak'
    at Function.Module._resolveFilename (module.js:338:15)
    at Function.Module._load (module.js:280:25)
    at Module.require (module.js:364:17)
    at require (module.js:380:17)

I can see that weakMap.js exists in the repository, but it's not in my node_modules memoizee folder.

Memoizing asynchronous functions

In the provided example, if I understand, returning something in err of the callback must result in cache miss?
'Operations that result with an error are not cached.'

var memoize = require('memoizee');
var memProfile = require('memoizee/profile');
var count = 0;
var afn = function test(a, b, cb) {
    count++;
    console.log('called '+ count);
    setTimeout(function () {
        cb('error', null);
    }, 200);
};
var memoized = memoize(afn, { async: true });

memoized(3, 7, function (err, res) {
    console.log('done 1');
    memoized(3, 7, function (err, res) {
        console.log('done 2');    
    });
});

memoized(3, 7, function (err, res) {
    console.log('done 3');
});

memoized(3, 7, function (err, res) {
    console.log('done 4');
});
memoized(3, 7, function (err, res) {
    console.log('done 5');
});

setTimeout(function () {
    console.log(memProfile.log());
},5000);

Results in 2 Init and 3 hit.
Can I have a working example?

In this code https://github.com/chrisdlangton/node-rest-demo/blob/master/routes/list.js (function handleFind ), I supose the missing callback explain the no cache hit?

Delete question

Is it possible to delete cached entries based upon just the first argument? In my case, I have a memoized function that caches a transform based upon different groupings. When the underlying data is changed I want to delete all of the groupings in the cache for that object but leave all other groupings for other objects intact. Is this possible?

Register callback when cache reaches max size

It would be nice to be able to register a callback when the cache reaches its max size. Even better if the value being evicted could be accessed.

The use case I'm after is being able to log out when a cached method result is going to be evicted for debugging/perf analysis purposes.

I tried to use the dispose callback for this but realized it was only called when clear() is called.

Apologies if I missed something in the docs and if this is possible!

Easiest way to ignore an argument for memoization

Let's say I have an async function:

function verifyToken(token, fn) {
   ...
}`;

This can easily be momoized with something like:

var memoized = memoize(verifyToken, {async: true, length: 1});

What if I have a function:

function verifyToken(req, token, fn) {
  ...
}`;

where req is Express request object. I would not like the req value to be considered for hashing at all. We should still memoize results of verifyToken based on token value only. What's the easiest approach to accomplish this? Resolvers? Something like:

var memoized = memoize(verifyToken, {async: true, length: 2, resolvers: [Boolean, String]});

? This way req (which will always be there) will always just be coersed to true and token will be coersed to String as normal. Just want to check if this the best approach? Thanks!

how do I use in the browser?

Hi, I am trying to use Webmake to generate a browser compatible build. I have built using web make index.js bundle.js and then included bundle.js in my index.html.

However when I try to call memoize in my js I get an error memoize is not defined - how am I meant to call the function?

prefetch doesn't work with async

I'm having problem with prefetch in combination with async. Is this supported? It seems like the prefetch is calling the function without any arguments.

max and maxAge in combination with async: true lead blocking of event loop

Consider the following example:

var memoize = require("memoizee");

var mem = memoize(function (returnError, callback) {
    setTimeout(function () {
        if (returnError) {
            callback(new Error("My Error"));
        } else {
            callback(null, true);
        }
    }, 50);
}, {
    async: true,
    maxAge: 50,
    max: 10,
    preFetch: false
});

mem(true, function (err, value) {
    if (err) {
        console.log("Error: " + err.message);
    } else {
        console.log("Value: " + value);
    }
});

mem(false, function (err, value) {
    if (err) {
        console.log("Error: " + err.message);
    } else {
        console.log("Value: " + value);
    }
});

console.log("Let's wait a bit...");

setTimeout(function () {
    console.log("Enough waiting!");
    process.exit(0);
}, 30000);

This will send memoizee into an infinite loop.

additional information

$ node --version
v0.10.20

$ npm ls
└─┬ [email protected]
  ├── [email protected]
  ├── [email protected]
  └── [email protected]

Graceful handling of un-refreshable

Hello,

I'd love a way to be able to have my method throw a special exception (or return a special value) that indicates that a refresh at this time is not possible, causing the old expired data to continue to be used.

Ideally the exception could also specify some kind of retry policy: wait 20% more expiry before trying again.

Memoize wraps an HTTP client in my case, and I'd like to build in a way of dealing with the target service being absent.

Function with object as parameters

Memoize works with strings and numbers but not with more complex parameters like objects like {x:1, y: 1}

Here the pice of code:

var m = require("memoizee");

// not a big deal!
var f = function(a,b)  { console.log(arguments);}

var mf = m(f);

// I had a miss
mf(1,2)
{ '0': 1, '1': 2 }

// I had a hit and that's fine!
mf(1,2)

// Now

// In both successive calls I always got a miss 
mf(1,{ x:1, y:1})
{ '0': 1, '1': { x: 1, y: 1 } }

mf(1,{ x:1, y:1})
{ '0': 1, '1': { x: 1, y: 1 } }

I will be nice to have deep comparison, won't it? May be there is a performance consideration to have.

Memory optimization

Currently for each memoized function there are few functions created, that affects memory badly when our configration deals with thousands of memoized instances. It'll be much more optimal to rely on prototype inheritance model in that case

Improve cache logic for prefetch

Current prefetch implementation drops cache value immediately after start. That's not correct behaviour for big loads. Cache should be dropped only if it's timed out, and should not be affected by internal failures.

Summary:

  1. If prefetch "in progress", memoizee should return old cache value.
  2. When prefetch complete:
    • on successs - update cache value
    • on fail - do nothing.

Potential problem:

If prefetch fails, it will be called again on next memoizee call (no throttling). That can be considered as acceptable behaviour, because:

  • it still suppress parallel calls
  • it does not increase latency

profiler not working?

I can't seem to get anything useful from the profiler. I'm running npm version 0.3.2, with the following code:

var memProfile = require('memoizee/profile'),
    memoize = require('memoizee'),
    eyes = require('eyes');

function doIt(cb) {
    setImmediate(function() {console.log("did it!");cb();})
}

function done(err) {
    if (err) console.error(err);
    console.log("done");
}

eyes.inspect(memProfile.statistics);

doIt(done);

eyes.inspect(memProfile.statistics);

var maybeDoIt = memoize(doIt, {async: true});

eyes.inspect(memProfile.statistics);

maybeDoIt(done);
maybeDoIt(done);
maybeDoIt(done);
maybeDoIt(done);
maybeDoIt(done);

setImmediate(function() {eyes.inspect(memProfile.statistics);});

This generates the following output:

{}
{}
{}
did it!
done
did it!
done
done
done
done
done
{}

Am I misusing the profiler? Swapping the require order of memoizee and the profiler didn't help at all.

memoize & prefetch promises

I'm rewriting a lot of code from callbacks to yield + promises. Would like to find a nice solution to memoize results from db in new style.

I can memoize sync function, that return Promise. That looks ok until promise fails - such result should not be reused. Any ideas how to deal with it?

PS. I know i can use old style internals and promisify memoized function, but that's not beautiful.

Filtered array memoization?

I'm trying to get create a memoized function that picks "selected" items out of a ...byId object. I'm hoping to cache the result when the selection didn't change and when the selected objects didn't change. This is important because I'd like to pass the result to other (expensive) regularly memoized functions.
Not memoized example:

const state = {
    objectsById: {
        a: { health: 1, ... },
        b: { health: 0.5, ... },
        c: { health: 1, ... }
    }, 
    selection: ['a', 'b']
};
function getSelectedObjects(state) { // how to memoize? 
    return state.selection.map(({id}) => state.objectsById[id]);
}

I can implement a crude custom shallow array "memoizer", but is there a way to do this with memoizee? I'd like to benefit from it's other features. Is there for example a way to implement a custom compare function?

An crude implementation of the desired behaivior:

const state = {
    objectsById: {
        a: { health: 1 },
        b: { health: 0.5 },
        c: { health: 1 }
    }, 
    selection: ['a', 'b']
};

function getSelectedObjectsTransform(state) {
    return state.selection.map(id => state.objectsById[id]);
}
const getSelectedObjects = arrayMemoizer(getSelectedObjectsTransform);
getSelectedObjects(state));

function arrayMemoizer(fn) {
    let prevArg; 
    let prevResult;
    return function(arg) {
        // if same arguments; return prev result; 
        if(arg === prevArg && prevResult) {
            return prevResult;
        }
        prevArg = arg;

        const result = fn(arg);
        // if no prevResult; return new result
        if(!prevResult) {
            return prevResult = result;
        }
        // if length changed; return new result
        if(result.length !== prevResult.length) {
            return prevResult = result;
        }
        // if item in array changed; return new result 
        for(let index in result) {
            let item = result[index];
            let prevItem = prevResult[index];
            if(item !== prevItem) {
                return prevResult = result;
            }
        }
        // return prev result
        return prevResult;
    }
}

How to clear cache on parameter change

I want to use memoize with immutable.js and redux instead of reselect that the redux docs mention and I have the following use case which I think is very common:

The function signature:

function doSomething(state, param1, param2)

What is special about this function is that if the state changes, the whole cache should be cleared because it is a function that derives data from the current state of the app. One way I am thinking could solve this is to wrap this in a factory function just on the state and then cache that on the params. Something like:

memoize(state => memoize((param1, param2) => {...}))

Is this the best and perhaps only way to do it? And would this perform or is the memoize function call expensive? I know it´s a relative question and I should and will benchmark this but perhaps you already know the answer to this, especially the "is there a better way" one.

`resolvers` are called inconsistently

Depending on the length of resolvers, they may or may not be called before passing the results to the wrapped function:

> m = require('memoizee')
[Function]
// 1-arg, 1-resolver
> m(function(arg) { console.log('arguments:', arg); }, { resolvers: [ () => 'foo' ] })('a')
arguments: a
undefined
// 2-arg, 2-resolver
> m(function(arg1, arg2) { console.log('arguments:', arg1, arg2); }, { resolvers: [ () => 'foo', () => 'bar' ] })('a', 'b')
arguments: foo bar
undefined
// 1-arg, 2-resolver
> m(function(arg) { console.log('arguments:', arg); }, { resolvers: [ () => 'foo', () => 'bar' ] })('a')
arguments: foo
undefined

The docs are a little unclear on the exact semantics of resolvers, but I take it to mean that the wrapped function should never receive the output of resolvers as it is here.

more flexible maxAge

Some things which I find myself wanting:

  • ability to change maxAge on the fly
  • ability to set maxAge for an individual item

crash report: memoize async + async.eachSeries

The following test code causes memoizee to spin into a nextTick() loop and blow the callstack.

var memoize = require('memoizee'),
    async = require('async'),
    ar = [];

for (i=0;i<2500;i++) {
    ar.push(i);
}

var test = memoize(function(id, cb) {
    cb(null, id);
}, {
    async: true,
    maxAge: 5000,
    max: 10000,
    prefetch: true,
    primitive: true
});

function test2() {
    console.log("start");
    async.eachSeries(ar, function(j, cb) {
        test(j, cb);
    }, function (err) {
        if (err) {
            console.error(err);
        }
        console.log("Done");
    });
}

setInterval(test2, 5000);

This will crash on the second interval.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.