-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unrealistic / flawed cache benchmarking #83
Comments
I read this: https://community.risingstack.com/the-worlds-fastest-javascript-memoization-library/ and came to the same conclusion. It seems that almost every memoization library address the hard problems by ignoring them. Serialization is incredibly expensive if you're trying to memoize non-trivial objects. In my case, megabytes of tens of thousands of GeoJSON features. A solution I'm looking into is a tree of Map objects:
If anyone's interested in chatting about this, I'm all ears. I think I will likely explore this practically and do some comparisons. |
I built one based on a tree of maps as you say, it uses a linked list to know which paths to cleanup but there are several other options. Memory leaks are definitely a consideration but also picking a good cache size. If you pick a cache size of n-1 and functions are executed in round robin you'll end up with constant cache misses. Often updating the cache size dynamically is important in such cases. Another consideration is that if you have a very small cache size you might be better off just doing a nested for loop for finding a cache entry. TL;DR: it really depends on your execution pattern |
Thanks for the details and links. I hadn't seen a few of those options. I found memoizee but just couldn't unravel how they do caching with efficient lookup. Looks like I get to spend my time doing something other than building yet another memo library =) |
FYI, we implemented benchmarking with more realistic data (memoized functions are being called with a set of 1000 different arguments over and over again, instead of with just one and the same or just a handful of different arguments). The results for fast-memoize are far from being the fastest: https://github.com/Animus-Blue/sonic-memoize |
The cache benchmarking has a few issues:
Map
is ideal for caching based on an object argument because v8 and other engines assign a random ID to every object under the hood and checking if it is the same object is as simple as comparing two ints. The cache benchmarking code should test massive objects as arguments to the memoization function.Map
is specifically designed with key deletion in mind whereas hidden classes on objects are not so well suited to this. Keys are likely to be added and deleted a lot in a memoized function so it's important to model this.The text was updated successfully, but these errors were encountered: