lru-cache vs quick-lru vs node-cache vs memory-cache
In-Memory Caching Libraries for Node.js Comparison
Search packages..
3 Years
lru-cachequick-lrunode-cachememory-cacheSimilar Packages:
What's In-Memory Caching Libraries for Node.js?

In-memory caching libraries for Node.js provide a way to store data temporarily in the server's memory, allowing for faster access compared to retrieving data from a database or external source. These libraries are useful for caching frequently accessed data, reducing latency, and improving the performance of applications. They typically offer features like time-to-live (TTL) for cached items, eviction policies to manage memory usage, and support for storing key-value pairs. Examples include lru-cache, memory-cache, node-cache, and quick-lru, each with its own unique features and use cases.

Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
Package
Downloads
Stars
Size
Issues
Publish
License
lru-cache239,402,483
5,673827 kB122 days agoISC
quick-lru25,331,113
72116.4 kB416 days agoMIT
node-cache3,622,949
2,350-735 years agoMIT
memory-cache637,899
1,601-328 years agoBSD-2-Clause
Feature Comparison: lru-cache vs quick-lru vs node-cache vs memory-cache

Eviction Policy

  • lru-cache:

    lru-cache implements the Least Recently Used (LRU) eviction policy, which removes the least recently accessed items when the cache reaches its size limit. This helps keep the most frequently used items in memory while freeing up space for new ones.

  • quick-lru:

    quick-lru uses the LRU (Least Recently Used) eviction policy to remove the least recently accessed items when the cache reaches its maximum size. This ensures that the cache retains the most frequently used items while efficiently managing memory.

  • node-cache:

    node-cache supports TTL (time-to-live) for cached items, and it automatically removes expired items. It does not implement a specific eviction policy like LRU, but it manages memory efficiently by cleaning up expired entries.

  • memory-cache:

    memory-cache does not have a built-in eviction policy, as it is a simple key-value store. However, it allows you to set expiration times (TTL) for cached items, after which they will be automatically removed from the cache.

Time-to-Live (TTL) Support

  • lru-cache:

    lru-cache does not natively support TTL for cached items, but you can implement it manually by tracking expiration times and removing items as needed.

  • quick-lru:

    quick-lru does not support TTL natively, but you can implement it externally. It focuses on LRU eviction without built-in expiration features.

  • node-cache:

    node-cache has built-in support for TTL, allowing you to set expiration times for cached items. Expired items are automatically cleaned up, making it easy to manage stale data.

  • memory-cache:

    memory-cache allows you to set TTL for each cached item, after which the item will expire and be removed from the cache automatically.

API Simplicity

  • lru-cache:

    lru-cache provides a simple and intuitive API for setting, getting, and deleting cached items. Its focus on LRU caching makes it easy to use without unnecessary complexity.

  • quick-lru:

    quick-lru boasts a minimalistic API that emphasizes speed and simplicity. It is designed for developers who need a fast LRU cache without any frills.

  • node-cache:

    node-cache features a user-friendly API with additional methods for managing TTL, retrieving cache statistics, and handling expired items. It is more feature-rich while still being easy to use.

  • memory-cache:

    memory-cache offers a straightforward API for basic caching operations. Its simplicity makes it easy to integrate into projects without a steep learning curve.

Memory Management

  • lru-cache:

    lru-cache allows you to set a maximum size for the cache, which helps control memory usage. When the limit is reached, the least recently used items are automatically evicted to free up space.

  • quick-lru:

    quick-lru allows you to set a maximum size for the cache, ensuring that memory usage is kept in check. The LRU eviction policy helps maintain efficient memory usage by removing the least recently used items.

  • node-cache:

    node-cache manages memory efficiently by cleaning up expired items automatically. However, it does not have a hard limit on memory usage, so it is important to monitor cache size in long-running applications.

  • memory-cache:

    memory-cache does not impose any memory limits, which can lead to unbounded memory usage if not managed carefully. It is best used for small to moderate amounts of cached data.

Ease of Use: Code Examples

  • lru-cache:

    LRU Cache Example

    const LRU = require('lru-cache');
const options = { max: 100 }; // Set maximum cache size
const cache = new LRU(options);

// Set cache items
cache.set('key1', 'value1');
cache.set('key2', 'value2');

// Get cache items
console.log(cache.get('key1')); // Output: value1

// Cache size
console.log(cache.size); // Output: 2

// Evicting items
cache.set('key3', 'value3'); // This will evict the least recently used item (key1)
console.log(cache.get('key1')); // Output: undefined
  • quick-lru:

    Quick LRU Example

    const QuickLRU = require('quick-lru');
const lru = new QuickLRU({ maxSize: 100 }); // Set max size

// Add items to cache
lru.set('key1', 'value1');
lru.set('key2', 'value2');

// Get cached item
console.log(lru.get('key1')); // Output: value1

// Check cache size
console.log(lru.size); // Output: 2

// Evicting items
lru.set('key3', 'value3'); // This will evict the least recently used item (key1)
console.log(lru.get('key1')); // Output: undefined
  • node-cache:

    Node Cache Example

    const NodeCache = require('node-cache');
const cache = new NodeCache({ stdTTL: 100, checkperiod: 120 }); // TTL: 100 seconds

// Set cache item
cache.set('key1', 'value1');

// Get cache item
console.log(cache.get('key1')); // Output: value1

// Check TTL and expire item
setTimeout(() => {
  console.log(cache.get('key1')); // Output: null (item expired)
}, 110000);

// Cache stats
console.log(cache.getStats());
  • memory-cache:

    Memory Cache Example

    const cache = require('memory-cache');

// Set cache with TTL (time-to-live)
cache.put('key1', 'value1', 5000); // Expires in 5 seconds

// Get cache item
console.log(cache.get('key1')); // Output: value1

// Wait for 6 seconds
setTimeout(() => {
  console.log(cache.get('key1')); // Output: null (item expired)
}, 6000);
How to Choose: lru-cache vs quick-lru vs node-cache vs memory-cache
  • lru-cache:

    Choose lru-cache if you need a simple and efficient implementation of the Least Recently Used (LRU) caching algorithm. It is ideal for scenarios where you want to limit memory usage while keeping frequently accessed items readily available.

  • quick-lru:

    Use quick-lru when you need a lightweight and fast LRU cache implementation with a minimalistic API. It is perfect for performance-sensitive applications where simplicity and speed are priorities.

  • node-cache:

    Opt for node-cache if you need a feature-rich caching solution with built-in support for TTL, automatic cleanup of expired items, and a simple API. It is well-suited for applications that require more control over cache management.

  • memory-cache:

    Select memory-cache for a straightforward key-value store with support for time-to-live (TTL) expiration. It is easy to use and suitable for applications that require basic caching functionality without complex configurations.

Similar Npm Packages to lru-cache

lru-cache is a popular caching library for Node.js and JavaScript applications that implements a Least Recently Used (LRU) caching strategy. This means that it automatically removes the least recently accessed items from the cache when it reaches its maximum size, ensuring that the most frequently used data remains available. This makes lru-cache an excellent choice for optimizing performance in applications that require quick access to frequently used data.

While lru-cache is a robust solution for caching, there are several alternatives available that also provide caching capabilities. Here are a few notable options:

  • memory-cache is a simple and lightweight caching library for Node.js applications. It allows you to store key-value pairs in memory with an optional expiration time. Unlike lru-cache, memory-cache does not implement an LRU eviction policy, making it a straightforward choice for applications that require basic caching without the complexity of eviction strategies. It's ideal for small projects or scenarios where caching needs are minimal.

  • node-cache is another caching library designed specifically for Node.js applications. It provides a simple API for storing and retrieving data in memory, along with features like time-to-live (TTL) for cache entries. While it does not implement an LRU eviction policy by default, it offers a more comprehensive set of features compared to memory-cache, making it suitable for applications that require more control over caching behavior.

  • quick-lru is a lightweight and fast LRU cache implementation for JavaScript. It is designed to be simple and efficient, providing a minimal API for managing cached items. quick-lru is an excellent choice for developers looking for a straightforward LRU caching solution without the overhead of additional features. Its performance and simplicity make it a great alternative for applications that need efficient caching without unnecessary complexity.

To see how lru-cache compares with memory-cache, node-cache, and quick-lru, check out the comparison: Comparing lru-cache vs memory-cache vs node-cache vs quick-lru.

Similar Npm Packages to quick-lru

quick-lru is a lightweight and efficient caching library for Node.js applications. It implements a Least Recently Used (LRU) cache, which automatically removes the least recently accessed items when the cache reaches its limit. This makes it an ideal choice for applications that require fast access to frequently used data while efficiently managing memory usage. While quick-lru is a solid option for caching, there are several alternatives available in the ecosystem. Here are a few notable ones:

  • cache-manager is a versatile caching library that provides a simple and consistent API for managing various caching stores. It supports multiple backends, including memory, Redis, and more, allowing developers to choose the most suitable storage mechanism for their applications. If you need a more comprehensive caching solution that can work with different storage options and provides additional features like cache expiration and serialization, cache-manager is an excellent choice.
  • cacheable-request is a caching library specifically designed for HTTP requests. It wraps around the native http and https modules, allowing developers to easily cache responses from HTTP requests. This library is particularly useful for applications that make frequent API calls and want to reduce the number of requests sent to the server. If your primary focus is on caching HTTP responses, cacheable-request is a great option.
  • lru-cache is another popular LRU caching library that provides a simple and efficient way to manage in-memory caches. It allows developers to set a maximum size for the cache and automatically evicts the least recently used items when the limit is reached. With its straightforward API and good performance, lru-cache is a solid choice for applications that require a reliable in-memory caching solution.
  • memory-cache is a simple in-memory caching library that provides basic caching functionality. It allows developers to store key-value pairs in memory and set expiration times for cached items. While it may not have all the advanced features of other libraries, memory-cache is easy to use and can be a good fit for smaller applications or projects that require basic caching capabilities.

To see how quick-lru compares with cache-manager, cacheable-request, lru-cache, and memory-cache, check out the comparison: Comparing cache-manager vs cacheable-request vs lru-cache vs memory-cache vs quick-lru.

Similar Npm Packages to node-cache

node-cache is a simple and efficient caching module for Node.js applications. It provides an easy-to-use API for storing and retrieving cached data in memory, making it ideal for scenarios where quick access to frequently used data is required. With features like time-to-live (TTL) for cache entries and automatic cleanup of expired items, node-cache helps improve application performance by reducing the need for repeated data fetching or computation.

While node-cache is a solid choice for in-memory caching, there are several alternatives that offer different features and capabilities. Here are a few notable options:

  • lru-cache is a popular caching library that implements a Least Recently Used (LRU) caching strategy. This means that when the cache reaches its limit, it automatically removes the least recently accessed items to make space for new ones. lru-cache is particularly useful for applications that require efficient memory management and want to ensure that frequently accessed data remains available. Its flexibility and performance make it a great choice for caching scenarios where memory constraints are a concern.

  • memory-cache is another lightweight caching library for Node.js that provides a simple API for in-memory caching. It allows developers to store key-value pairs with optional expiration times. While memory-cache is straightforward and easy to use, it does not implement advanced caching strategies like LRU. It is best suited for smaller applications or scenarios where simplicity is preferred over complex caching mechanisms.

  • node-persist is a persistent storage library for Node.js that allows you to store data in a file-based cache. Unlike in-memory caching solutions, node-persist provides durability by saving data to the filesystem, making it suitable for applications that require data persistence across restarts. It offers a simple API for storing and retrieving data, along with features like automatic serialization and deserialization of JavaScript objects.

To compare these caching libraries, check out the following link: Comparing lru-cache vs memory-cache vs node-cache vs node-persist.

Similar Npm Packages to memory-cache

memory-cache is a simple and efficient caching library for Node.js applications. It allows developers to store key-value pairs in memory, providing a fast way to access frequently used data without the need for repeated calculations or database queries. While memory-cache is a great choice for in-memory caching, there are several alternatives that offer similar functionality. Here are a few noteworthy options:

  • lru-cache is a popular caching library that implements a Least Recently Used (LRU) cache algorithm. This means that it automatically removes the least recently accessed items when the cache reaches its limit, making it ideal for applications where memory usage needs to be optimized. lru-cache is particularly useful for scenarios where you want to maintain a limited amount of cached data while ensuring that the most frequently accessed items remain available. Its flexibility and efficiency make it a preferred choice for many developers looking for a robust caching solution.
  • node-cache is another caching library designed specifically for Node.js applications. It provides a simple API for storing and retrieving cached data, along with features like time-to-live (TTL) for cache entries, allowing developers to set expiration times for cached items. node-cache is well-suited for applications that require a straightforward caching mechanism with the ability to manage cache lifetimes effectively. Its ease of use and built-in expiration features make it a solid choice for many caching scenarios.
  • quick-lru is a lightweight and efficient LRU caching library that focuses on performance. It is designed to be simple and fast, making it an excellent choice for applications that require a minimalistic approach to caching. quick-lru allows developers to easily set limits on the cache size and provides a straightforward API for adding and retrieving cached items. If you are looking for a high-performance caching solution without unnecessary complexity, quick-lru is worth considering.

To see how memory-cache compares with lru-cache, node-cache, and quick-lru, check out the comparison: Comparing lru-cache vs memory-cache vs node-cache vs quick-lru.

README for lru-cache

lru-cache

A cache object that deletes the least-recently-used items.

Specify a max number of the most recently used items that you want to keep, and this cache will keep that many of the most recently accessed items.

This is not primarily a TTL cache, and does not make strong TTL guarantees. There is no preemptive pruning of expired items by default, but you may set a TTL on the cache or on a single set. If you do so, it will treat expired items as missing, and delete them when fetched. If you are more interested in TTL caching than LRU caching, check out @isaacs/ttlcache.

As of version 7, this is one of the most performant LRU implementations available in JavaScript, and supports a wide diversity of use cases. However, note that using some of the features will necessarily impact performance, by causing the cache to have to do more work. See the "Performance" section below.

Installation

npm install lru-cache --save

Usage

// hybrid module, either works
import { LRUCache } from 'lru-cache'
// or:
const { LRUCache } = require('lru-cache')
// or in minified form for web browsers:
import { LRUCache } from 'http://unpkg.com/lru-cache@9/dist/mjs/index.min.mjs'

// At least one of 'max', 'ttl', or 'maxSize' is required, to prevent
// unsafe unbounded storage.
//
// In most cases, it's best to specify a max for performance, so all
// the required memory allocation is done up-front.
//
// All the other options are optional, see the sections below for
// documentation on what each one does.  Most of them can be
// overridden for specific items in get()/set()
const options = {
  max: 500,

  // for use with tracking overall storage size
  maxSize: 5000,
  sizeCalculation: (value, key) => {
    return 1
  },

  // for use when you need to clean up something when objects
  // are evicted from the cache
  dispose: (value, key, reason) => {
    freeFromMemoryOrWhatever(value)
  },

  // for use when you need to know that an item is being inserted
  // note that this does NOT allow you to prevent the insertion,
  // it just allows you to know about it.
  onInsert: (value, key, reason) => {
    logInsertionOrWhatever(key, value)
  },

  // how long to live in ms
  ttl: 1000 * 60 * 5,

  // return stale items before removing from cache?
  allowStale: false,

  updateAgeOnGet: false,
  updateAgeOnHas: false,

  // async method to use for cache.fetch(), for
  // stale-while-revalidate type of behavior
  fetchMethod: async (
    key,
    staleValue,
    { options, signal, context },
  ) => {},
}

const cache = new LRUCache(options)

cache.set('key', 'value')
cache.get('key') // "value"

// non-string keys ARE fully supported
// but note that it must be THE SAME object, not
// just a JSON-equivalent object.
var someObject = { a: 1 }
cache.set(someObject, 'a value')
// Object keys are not toString()-ed
cache.set('[object Object]', 'a different value')
assert.equal(cache.get(someObject), 'a value')
// A similar object with same keys/values won't work,
// because it's a different object identity
assert.equal(cache.get({ a: 1 }), undefined)

cache.clear() // empty the cache

If you put more stuff in the cache, then less recently used items will fall out. That's what an LRU cache is.

For full description of the API and all options, please see the LRUCache typedocs

Storage Bounds Safety

This implementation aims to be as flexible as possible, within the limits of safe memory consumption and optimal performance.

At initial object creation, storage is allocated for max items. If max is set to zero, then some performance is lost, and item count is unbounded. Either maxSize or ttl must be set if max is not specified.

If maxSize is set, then this creates a safe limit on the maximum storage consumed, but without the performance benefits of pre-allocation. When maxSize is set, every item must provide a size, either via the sizeCalculation method provided to the constructor, or via a size or sizeCalculation option provided to cache.set(). The size of every item must be a positive integer.

If neither max nor maxSize are set, then ttl tracking must be enabled. Note that, even when tracking item ttl, items are not preemptively deleted when they become stale, unless ttlAutopurge is enabled. Instead, they are only purged the next time the key is requested. Thus, if ttlAutopurge, max, and maxSize are all not set, then the cache will potentially grow unbounded.

In this case, a warning is printed to standard error. Future versions may require the use of ttlAutopurge if max and maxSize are not specified.

If you truly wish to use a cache that is bound only by TTL expiration, consider using a Map object, and calling setTimeout to delete entries when they expire. It will perform much better than an LRU cache.

Here is an implementation you may use, under the same license as this package:

// a storage-unbounded ttl cache that is not an lru-cache
const cache = {
  data: new Map(),
  timers: new Map(),
  set: (k, v, ttl) => {
    if (cache.timers.has(k)) {
      clearTimeout(cache.timers.get(k))
    }
    cache.timers.set(
      k,
      setTimeout(() => cache.delete(k), ttl),
    )
    cache.data.set(k, v)
  },
  get: k => cache.data.get(k),
  has: k => cache.data.has(k),
  delete: k => {
    if (cache.timers.has(k)) {
      clearTimeout(cache.timers.get(k))
    }
    cache.timers.delete(k)
    return cache.data.delete(k)
  },
  clear: () => {
    cache.data.clear()
    for (const v of cache.timers.values()) {
      clearTimeout(v)
    }
    cache.timers.clear()
  },
}

If that isn't to your liking, check out @isaacs/ttlcache.

Storing Undefined Values

This cache never stores undefined values, as undefined is used internally in a few places to indicate that a key is not in the cache.

You may call cache.set(key, undefined), but this is just an alias for cache.delete(key). Note that this has the effect that cache.has(key) will return false after setting it to undefined.

cache.set(myKey, undefined)
cache.has(myKey) // false!

If you need to track undefined values, and still note that the key is in the cache, an easy workaround is to use a sigil object of your own.

import { LRUCache } from 'lru-cache'
const undefinedValue = Symbol('undefined')
const cache = new LRUCache(...)
const mySet = (key, value) =>
  cache.set(key, value === undefined ? undefinedValue : value)
const myGet = (key, value) => {
  const v = cache.get(key)
  return v === undefinedValue ? undefined : v
}

Performance

As of January 2022, version 7 of this library is one of the most performant LRU cache implementations in JavaScript.

Benchmarks can be extremely difficult to get right. In particular, the performance of set/get/delete operations on objects will vary wildly depending on the type of key used. V8 is highly optimized for objects with keys that are short strings, especially integer numeric strings. Thus any benchmark which tests solely using numbers as keys will tend to find that an object-based approach performs the best.

Note that coercing anything to strings to use as object keys is unsafe, unless you can be 100% certain that no other type of value will be used. For example:

const myCache = {}
const set = (k, v) => (myCache[k] = v)
const get = k => myCache[k]

set({}, 'please hang onto this for me')
set('[object Object]', 'oopsie')

Also beware of "Just So" stories regarding performance. Garbage collection of large (especially: deep) object graphs can be incredibly costly, with several "tipping points" where it increases exponentially. As a result, putting that off until later can make it much worse, and less predictable. If a library performs well, but only in a scenario where the object graph is kept shallow, then that won't help you if you are using large objects as keys.

In general, when attempting to use a library to improve performance (such as a cache like this one), it's best to choose an option that will perform well in the sorts of scenarios where you'll actually use it.

This library is optimized for repeated gets and minimizing eviction time, since that is the expected need of a LRU. Set operations are somewhat slower on average than a few other options, in part because of that optimization. It is assumed that you'll be caching some costly operation, ideally as rarely as possible, so optimizing set over get would be unwise.

If performance matters to you:

  1. If it's at all possible to use small integer values as keys, and you can guarantee that no other types of values will be used as keys, then do that, and use a cache such as lru-fast, or mnemonist's LRUCache which uses an Object as its data store.

  2. Failing that, if at all possible, use short non-numeric strings (ie, less than 256 characters) as your keys, and use mnemonist's LRUCache.

  3. If the types of your keys will be anything else, especially long strings, strings that look like floats, objects, or some mix of types, or if you aren't sure, then this library will work well for you.

    If you do not need the features that this library provides (like asynchronous fetching, a variety of TTL staleness options, and so on), then mnemonist's LRUMap is a very good option, and just slightly faster than this module (since it does considerably less).

  4. Do not use a dispose function, size tracking, or especially ttl behavior, unless absolutely needed. These features are convenient, and necessary in some use cases, and every attempt has been made to make the performance impact minimal, but it isn't nothing.

Breaking Changes in Version 7

This library changed to a different algorithm and internal data structure in version 7, yielding significantly better performance, albeit with some subtle changes as a result.

If you were relying on the internals of LRUCache in version 6 or before, it probably will not work in version 7 and above.

Breaking Changes in Version 8

  • The fetchContext option was renamed to context, and may no longer be set on the cache instance itself.
  • Rewritten in TypeScript, so pretty much all the types moved around a lot.
  • The AbortController/AbortSignal polyfill was removed. For this reason, Node version 16.14.0 or higher is now required.
  • Internal properties were moved to actual private class properties.
  • Keys and values must not be null or undefined.
  • Minified export available at 'lru-cache/min', for both CJS and MJS builds.

Breaking Changes in Version 9

  • Named export only, no default export.
  • AbortController polyfill returned, albeit with a warning when used.

Breaking Changes in Version 10

  • cache.fetch() return type is now Promise<V | undefined> instead of Promise<V | void>. This is an irrelevant change practically speaking, but can require changes for TypeScript users.

For more info, see the change log.

npm-compare.com is an independent website designed to help developers choose the most suitable npm packages. We are not affiliated with npm, Inc or npmjs.com, the official website for the npm registry. Please note that npm is a registered trademark of npm, Inc. For more details, please refer to our Terms & Privacy.