From 987e286de29b381a1575c3f906639f8dd305d0e1 Mon Sep 17 00:00:00 2001 From: Brian Ton Date: Tue, 7 Jan 2025 19:10:04 -0800 Subject: [PATCH] Update README.md a bit --- README.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 8747612..05e227e 100644 --- a/README.md +++ b/README.md @@ -31,7 +31,10 @@ WARN: could not fetch server CONFIG SET: 1723040.88 requests per second GET: 5471556.00 requests per second ``` -Speedup for `GET` is mostly due to concurrency, I believe (entire table is locked for `SET`, so not much speedup in that case). Could be improved with a sharded concurrent map library? +Speedup for `GET` is mostly due to concurrency, I believe (entire table is locked for `SET`, so not much speedup in that case). Could be improved with a sharded concurrent map library? My initial trials say no, but intuitively, it should work. + +Also do take these benchmarks with a grain of salt - these were done on the Lenovo Yoga Slim 7i Aura edition (Intel Ultra 7 258v, 32GB), but definitely not a sanitized environment (many processes open in the background). Here, I believe we're benefitting a lot from the 8 cores and high memory speed (due to the memory being on the CPU package itself). Thus, your mileage may vary, and definitely do **not** use this for production. + ## TODO list - [x] Write some basic parser for RESP - [x] Get an MVP of basic SET / GET functionality