A mini redis in 411 lines of Python | Hacker News Reader

A mini redis in 411 lines of Python

github.com

35 pointsfogus7 comments

We use Redis in a large production site, and I could see something like as useful for automated testing. Also, if I wanted to add something to Redis, it would be much, much simpler to prototype it with miniredis in Python before hacking it into Redis proper in pure C.

Wouldn't it be completely useless to prototype something in python? Both memory and speed would be completely different.

For automated testing, redis is easy enough to start and stop. It compiles without dependencies and a simple "make" does the job :)

Not this stuff again. Yes, basically any service you can think of can be implemented trivially, if you don't have to worry about things like concurrency, performance, scalability, etc.

This might have been a nice learning experience for the author, but it's definitely not hacker news.

As the author, I agree. As I explicitly wrote in the README, I didn't find this project interesting and didn't think it'd be very useful for anyone in particular. Kiln ships with both a licensed on-site version, and a SaaS version. The SaaS version uses Redis as the backing for a small, easy-to-use queuing system. It was less work to write a tiny little clone of the parts of Redis the queuing system used than to write an entirely different pile of logic for Windows.

I think MiniRedis does what it needs to do well, but I was surprised to see it reasonably high on the HN page. I think there are probably more deserving projects out there.

The code handles concurrency the same way that redis handles concurrency. It's single threaded.

Redis 2 is multithreaded. The weird thing for me is that MiniRedis is 1/4th the speed of Redis 2 (using redis-bench, included with Redis 2, to measure), which means that being both single-threaded and written in a relatively slow scripting language didn't hurt performance that much. I haven't taken the time to figure out why; I thought Redis would be much faster.

Because Redis is in part I/O bound, this is why Redis 2.0, and even more Redis 2.2 (currently git master) are using the spare CPU in order to use less memory, with specially encoding for small lists, sets, hashes.

Btw 25% the speed means a lot slower :) My guess was that the difference for small keys that the redis-benchmark is stressing would be smaller.

I think that with big lists or using the SORT command the difference will be bigger.

Cheers, Salvatore

Reply on news.ycombinator.com