Benchmark: Lru cache FIXED 90 percent hit ratio

Tests:

Test1
"use strict"; let Lru = function(cacheSize,callbackBackingStoreLoad,elementLifeTimeMs=1000){ let me=this; let maxWait = elementLifeTimeMs; let size = parseInt(cacheSize,10); let mapping = {}; let buf = []; for(let i=0;i<size;i++) { let rnd = Math.random(); mapping[rnd] = i; buf.push({data:"",visited:false, key:rnd, time:Date.now()}); } let ctr= 0; let ctrEvict= parseInt(cacheSize/2,10); let loadData = callbackBackingStoreLoad; this.get = function(key){ if(key in mapping) { if(Date.now() - buf[mapping[key]].time > maxWait) { delete mapping[key]; return me.get(key); } else { buf[mapping[key]].visited=true; buf[mapping[key]].time = Date.now(); return buf[mapping[key]].data; } } else { let ctrFound = -1; while(ctrFound===-1) { if(buf[ctr].visited) { buf[ctr].visited=false; } ctr++; if(ctr >= size) { ctr=0; } if(!(buf[ctrEvict].visited)) { ctrFound = ctrEvict; } ctrEvict++; if(ctrEvict >= size) { ctrEvict=0; } } delete mapping[buf[ctrFound].key]; mapping[key] = ctrFound; let dataKey = loadData(key); buf[ctrFound] = {data:dataKey, visited:false, key:key,time:Date.now()}; return buf[ctrFound].data; } }; }; let lru = new Lru(9,function(key){ /* cache miss, load from data-store */ let wait=Date.now();let aa=0; while(Date.now()-wait<1){aa++;} return aa.toString()+key; },5000 /*miliseconds before next get() invalidates data */); let c=0; let tt=Date.now(); function runThis() { c++; let myData = lru.get(parseInt(Math.random()*10,10).toString()+"ee"); if(c<1000) runThis(); else console.log(Date.now()-tt); } runThis();
Test2
async function runThis() { for(let i=0;i<1000;i++) { let wait=Date.now();let aa=0; while(Date.now()-wait<1){aa++;} console.log(parseInt(Math.random()*10,10)); } } runThis();

Rendered benchmark preparation results:

Suite status: <idle, ready to run>

Previous results

Test case name	Result
Test1
Test2

Fastest: N/A

Slowest: N/A

Latest run results:

Run details: (Test run date: 7 months ago)

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36

Browser/OS: Chrome 125 on Windows

View result in a separate tab

Test name	Executions per second
Test1	9.2 Ops/sec
Test2	1.0 Ops/sec

Autogenerated LLM Summary (model llama3.2:3b, generated 2 months ago):

LLMs can make mistakes. Check important info.

Let's dive into the world of JavaScript microbenchmarks on MeasureThat.net!

**Benchmark Definition**

The provided JSON represents a benchmark definition for an LRU (Least Recently Used) cache implementation. The benchmark is designed to test the performance of the cache with different configurations.

In this case, we have two main components:

1. `Lru` function: This is the implementation of the LRU cache itself. It takes three arguments:
	* `cacheSize`: The size of the cache.
	* `callbackBackingStoreLoad`: A callback function to load data from a backing store (e.g., database, file system).
	* `elementLifeTimeMs`: The time window in milliseconds after which the cached data becomes invalid.

The LRU cache uses a simple algorithm to evict old items: when a new item is added, it checks if there are available slots in the cache. If not, it evicts the least recently used item by moving it to the end of the list and marking its timestamp as outdated.

2. `runThis` function: This is a test function that repeatedly calls the LRU cache with random keys. It's designed to simulate a caching scenario where data is frequently accessed and updated.

**Options Compared**

The benchmark compares different configurations by varying the `cacheSize`, `elementLifeTimeMs`, and other parameters. Some options might include:

* Different cache sizes (e.g., 5, 10, 20)
* Varying element life times (e.g., 1000ms, 5000ms, 20000ms)
* Using different backing store load callbacks
* Implementing the LRU cache with various algorithms or optimizations

**Pros and Cons**

When it comes to implementing an LRU cache, there are pros and cons to consider:

Pros:

* **Improved performance**: By evicting old items, the cache can reduce memory usage and improve access times.
* **Simplified implementation**: The simple algorithm used in this benchmark makes it easier to understand and implement.

Cons:

* **Inefficiency**: If the cache is too large or the element life time is too short, it may lead to frequent evictions and reduced performance.
* **Overhead**: Implementing an LRU cache requires additional logic and memory usage, which can add overhead to your application.

**Library and Purpose**

The `Lru` function uses a simple array-based implementation, but in real-world applications, you might want to use more advanced libraries like:

* `lru-cache`: A popular JavaScript library for implementing LRU caches.
* `Redis`: An in-memory data store that can be used as a backing store.

These libraries provide optimized implementations and features like automatic cache size adjustment, expiration policies, and concurrency support.

**Special JS Features**

This benchmark uses some special JavaScript features:

* **Async functions**: The `runThis` function uses an async function to simulate asynchronous operations.
* **Arrow functions**: The callback functions used in the LRU cache implementation are defined using arrow functions.

These features are not essential to understanding the basic concept of LRU caching, but they do make the implementation more concise and readable.

**Alternatives**

If you're interested in exploring alternative approaches to LRU caching or want to compare different implementations, you can try:

* **Redis**: As mentioned earlier, Redis is a popular in-memory data store that can be used as a backing store for LRU caches.
* **Memcached**: A high-performance caching system that uses a similar algorithm to the one implemented in this benchmark.
* **Java or C++ libraries**: There are many LRU cache implementations available in Java and C++, such as Guava's `Cache` class or the Google Test library's `lru_cache` function.

Related benchmarks:

Lru cache FIXED 90 percent hit ratio (version: 0)

Lru clock 2 hand version

Comparing performance of: Test1 vs Test2

Created: 3 years ago by: Guest

Jump to the latest result

Test1

Test2

Suite status: <idle, ready to run>

Experimental features:

Fastest: N/A

Slowest: N/A

Autogenerated LLM Summary (model llama3.2:3b, generated 2 months ago):