Performance Comparison of Redis List vs String for User History Storage

Modern development languages abstract memory management, but understanding the underlying mechanisms of open‑source components like Redis can still yield performance gains.

The business requirement is to store up to 10,000 integer IDs per user, read the entire set on each refresh, and append up to 10 new IDs, discarding the oldest when the limit is exceeded.

Redis solution 1: List – A Redis List naturally fits the scenario; $redis->lrange('TEST_KEY', 0,9999); reads all IDs, while $redis->lpush('TEST_KEY', 1,2,3,4,5,6,7,8,9,10); and $redis->ltrim('TEST_KEY', 0,9999); handle writes and size limiting. Benchmarking shows write time of ~0.066 ms per batch and read time exceeding 4 ms due to full traversal of the underlying doubly‑linked list.

Result snippet:

Write repeats:10000     time consume:0.65939211845398   each 6.5939211845398E-5<br/>Rrite repeats:10000     time consume:42.383342027664    each 0.0042383342027664

Redis solution 2: String – The IDs are concatenated into a single string separated by a delimiter (e.g., "_") and stored with $redis->set('TEST_KEY', implode('_', $userItems));. Reading involves $items = explode('_', $redis->get('TEST_KEY'));. This adds overhead for concatenation and splitting but benefits from sequential memory access.

Result snippet:

Write repeats:10000     time consume:6.4061808586121    each 0.00064061808586121<br/>Read repeats:10000      time consume:4.9698271751404    each 0.00049698271751404

Conclusion – The List approach offers extremely fast writes but slower reads because Redis implements lists as doubly‑linked structures, leading to random memory access. The String approach incurs higher write cost due to full rewrites but achieves roughly ten‑fold faster reads thanks to sequential I/O and better CPU cache utilization. Understanding these memory layouts enables developers to choose the optimal storage strategy even without direct low‑level memory manipulation.