The Life-Changing Magic of Tidying Ruby Object Allocations

Summary

The post presents object-allocation profiling as a way to find Ruby performance hotspots, including code inside libraries such as Active Record. It uses memory_profiler and derailed_benchmarks to group allocations by gem, file, and source location, then examines whether each allocation can be removed or avoided. A benchmark compares a direct maximum comparison with an array-based version: the array allocation makes the latter 2.04x slower in the reported run. One optimization for cache_version reuses a raw database timestamp string when it is safe, checking its type, format, timezone, and provenance before deleting separators and padding PostgreSQL-truncated values. This change reduces allocation from 743,842 bytes and 6,626 objects to 702,955 bytes and 6,063 objects, and the post reports up to 1.12x faster; combined optimizations reach 1.23x overall.

Takeaways

1. 1

   The reported array-allocation benchmark is 2.04x slower than a direct comparison of two values.

2. 2

   The cache_version fast path requires a String timestamp, :usec formatting, UTC timezone, and a value that did not come from the user.

3. 3

   The cache_version change cuts allocation by 40,887 bytes and 563 objects, while the post reports up to 1.12x faster performance; combined optimizations reach 1.23x.