Takeaways

1. Memory profiling is harder than CPU profiling (mostly because the tools are immature), but it can reveal more severe slowdowns. The more you use memory, the more time your program spends in garbage collection.

2. You can use ruby-prof and KCachegrind tools for memory profiling, but you need to run a patched Ruby. Fortunately, it’s easy to do so with rbenv and rvm.

3. Remember the little details that can make your profiles invalid. Turn off GC for CPU profiling, but leave it on for memory profiling, especially GC calls/time profiling.

4. Don’t use current memory usage and GC statistics for memory profiling unless you have no other choice. Those numbers are a function of current program state and GC settings; they aren’t repeatable in production. Optimize memory allocation instead.

Profiling is hard and intimidating when you first do it. I showed you some pitfalls—expect more. The good news is that once you’re comfortable profiling, you’ll start to find performance gems. Remember the Ruby iterators that allocate additional objects? Or String#gsub! that doesn’t really save any memory? I found these during my profiling sessions. You’ll make your own discoveries, which will make up for all your struggles with the profiler.

Now that you know how to optimize with the profiler, it’s time to step back and focus on measurement. We’ve measured execution time and memory usage before and after optimization. But did we do it right? The next chapter will answer that question.