A Rubyist's Walk Along the C-Side (Part 10): Benchmarking | Hacker News Reader

A Rubyist's Walk Along the C-Side (Part 10): Benchmarking

blog.peterzhu.ca

82 pointsthunderbong5 comments

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.

I imagine there may have been some room for improvement in the Ruby version, too

It largely depends where the bottleneck is. In this case it may be the algorithms and data structures chosen if the two implementations are equivalent in that respect. I would highly doubt any C++ implementation using a reasonably efficient implementation (avoiding quadratic algorithmic complexity) that only works on a local file of modest size would take anywhere near 800 seconds on any modern machine.

If you want to benchmark on a script level, I really recommend hyperfine: https://github.com/sharkdp/hyperfine

Almost thought that it was about about seaside / smalltalk ( https://www.seaside.st/ )

Reply on news.ycombinator.com