~/talk

How to Performance

Talkat RubyConf 2015 · 2015-11-15..11-17· [web-performance]
slides:none on file

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

  1. 0:00Intro
  2. 0:23How to PERFORMANCE
  3. 2:33CONSOLIDATE CODE
  4. 3:16BENCHMARKING VS PROFILING
  5. 3:42profiling what is slow
  6. 5:38Starting point: Ruby 2.1.5 Rails 4.2.0
  7. 6:37time was not a good baseline
  8. 8:49Sanity check: Ruby 2.1.5 2.2.0 Rails 4.2.0 master
  9. 10:13FIND THE CULPRITS
  10. 13:57Ruby Prof: Helped us compare integration and controller test stacks
  11. 16:54ALWAYS BE BENCHMARKING
  12. 17:37StackProf Disadvantage: X Bug in CPU time on OSX
  13. 19:11RubyVM.stat ruby standard library
  14. 25:47PROVE ALLOCATIONS ARE A BOTTLENECK
  15. 26:13Allocation Tracer: Helped us find unnecessary allocations of objects
  16. 27:14USE MULTIPLE
~/search
type to search 6,249 conferences, 138,987 speakers and 185,172 talks
~/help
cmdctrl k
search every conference, speaker and series
/
focus the filter search
h
home
c
conferences
s
speakers
e
series
t
light / dark — the status bar button does the same
?
this help
esc
close this, then clear every filter — or just the search, while you are typing in it

Ignored while you are typing. Pages without a filter rail have no search to focus.