Skip to content

notes - Profiling Ruby #38

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Aeon wants to merge 1 commit into
base: master
Choose a base branch
from
Open

notes - Profiling Ruby #38

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 41 additions & 0 deletions source/talks/profiling-ruby/notes/aeon-notes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
---
author: Anton Stroganov (@aeon)
---

Profiling ruby from top to bottom - [@xshay](http://twitter.com/xshay), engineer at Square

- Mindset is important.... Believe you can find something... usually, you will.

Three steps...
- Hypothesize
- Isolate
- Instrument

- Ok... so let's say Rails boot is slow...
- what does it do?
- isolate, run ruby commands with 'time' to check how much various stuff takes
- add a global timer from startup and add timestamp printouts at each major step...
- "caller" method will give you the stacktrace... so you can see what was called at any given point... and go and change it....
- added a stamp in the rails engine.rb :load_config_initializer to time each init... sometimes you find surprisingly stupid things.
- https://github.com/rails/rails/pull/12745

- Sometimes there is opposite problem - needing to prove something is fast
- benchmark a base and degenerate case...
- graph the benchmark... so you can actually interpret the data. gnuplot works...
- Suddenly you may find a low-level problem... uhoh...
- But C code is just code, even if it looks terrifying at first glance :) (this guy is funny as hell)
- The computer only does what you tell it to...
- Start by simply messing with the code... comment out branches and see what happens... just so you can get an idea of what is going on.
- rewrite the code as you read it in a language you are more familiar with - that actually makes sure that you understand what it does... even if it's ugly.
- eventually figure out the optimization which sometimes is surprisingly simple

- Ok, my unit tests are slow... what's going on.
- benchmark... you don't need to know how the code works or why it exists to benchmark it and find the bottlenecks.
- sometimes you find out that the code is using features it doesn't even need...

- other tools:
- perftools
- dtrace (with Flame graphs)
- strace

Also, pretty much everything at Square is either unit or integration tested... very very heavy coverage.