A couple of years ago, I was dealing with a Redis database that was leaking keys. One day the number of keys started to climb dramatically, and I had a difficul

A couple of years ago, I was dealing with a Redis database that was leaking keys. One day the number of keys started to climb dramatically, and I had a difficult time querying Redis itself to ask what the keys were, without it running out of memory as I did so. We were a Ruby shop, so I wrote a small Ruby tool to analyze the on-disk dump file. It would let me query the keyset, and count both the number and size (in bytes) of their data, matching some conditions. A pass of that tool took about 900 seconds to run on our dump. In between runs, I started rewriting the tool in C++ for better performance. This ultimately yielded a tool which took... 800 seconds to run. What I'd forgotten is that good, performant C code takes brain cells to write. I was able to get the C++ version's execution time down to 150 seconds, just with better memory management. The moral of my story is that Ruby isn't, on its face, considerably slower than "equivalent" C or C++ code. Rather, those languages allow more expressiveness in what the machine is going to do, under the hood, leading to more opportunities to optimize performance.