How to Performance
summary
A practical postmortem that claims integration tests go from 393 to 828 iterations per second and from 2.53× slower than controller tests to about 1.12× slower by combining measurement and fixes. It uses benchmark-ips, RubyProf, StackProf (wall time), RubyVM.stat and AllocationTracer to find CPU-sampling bugs, a Delegate regression, an extra constant from URLHelpers and heavy Rack string allocations; the team builds a test app, applies targeted fixes (move init, avoid cache where unnecessary, freeze few strings) and proves the gains.
AI-written summary · about
chapters (16)
- 0:00Intro
- 0:23How to PERFORMANCE
- 2:33CONSOLIDATE CODE
- 3:16BENCHMARKING VS PROFILING
- 3:42profiling what is slow
- 5:38Starting point: Ruby 2.1.5 Rails 4.2.0
- 6:37time was not a good baseline
- 8:49Sanity check: Ruby 2.1.5 2.2.0 Rails 4.2.0 master
- 10:13FIND THE CULPRITS
- 13:57Ruby Prof: Helped us compare integration and controller test stacks
- 16:54ALWAYS BE BENCHMARKING
- 17:37StackProf Disadvantage: X Bug in CPU time on OSX
- 19:11RubyVM.stat ruby standard library
- 25:47PROVE ALLOCATIONS ARE A BOTTLENECK
- 26:13Allocation Tracer: Helped us find unnecessary allocations of objects
- 27:14USE MULTIPLE
related talks
29mHow to Performance
01h 02mPerformance
42m3x Rails: Tuning the Framework Internals
44mWriting fast Ruby
45mRails Performance Monitoring 101: A Primer for Junior Developers
01h 15mSpeedupRails, Speedup Your Code
33m"It is correct, but is it fast?"
26mRails Performance Monitoring 101: A Primer for Developers
