You are not a machine. Stop trying to learn like one.
|
|
One thing I've always been frustrated by in performance-related discussion online is the focus on solutions.
It's an attitude I sometimes notice in my clients and workshop attendees. They seem to just want to know the Top 10 Things That Will Make Your Rails App Faster Right This Minute.
The problem is that there can be millions of different performance problems with your application. Web applications are built on top of dozens of different technology layers, each of which can be the cause of a performance issue. Talking about a single performance solution ("put CSS before JS in your head tags") is a bit like talking about a single brick in the Empire State Building: you need it, but there's a hell of a lot of other bricks.
There is an 80/20 rule style distribution to these problems, of course. I actually can teach you 10 things will fix 80% of your performance issues. But the other 20% requires a different mindset, and it's one I've always tried to teach: you are not a compiler, you're a scientist.
I think a lot about this slide that Vladimir Makarov put up at RubyKaigi 2019:
It's a list of 321 performance optimization passes that GCC makes over your code when you compile C. Many people seem to think that they should learn performance optimization this way: learn the 321 things that can go wrong in a Rails app, and then just think about them for every line of code you ever write ever again.
This approach works great for computers. But you are not a computer. You probably couldn't remember 20 performance optimization "passes" if you tried. And applying them to every line you ever write ever again? Forget about it.
Instead of thinking like a computer, you need to think like a scientist. Observe the world, make hypotheses about why it's that way, then experiment and test your hypotheses. This is the performance "uber-value" - if I can teach you how to do this, you can solve 3000 performance problems, not just 321.
It also eliminates unnecessary work: you can waste hours prematurely optimizing code that won't make a difference on production if you think with the "compiler" mindset. But if you think like a scientist, you'll only optimize code after you've observed it's issues and problems in the real world and prove that it's making an impact on real users.
So, instead of compiling:
1. Observe your application's behavior in the real world, using an APM tool like New Relic or Scout.
2. Notice problems, and examine them using profilers (stackprof) to form hypotheses about what's happening.
3. Reproduce locally, and use benchmarks to test your hypotheses ("if I change this, will it make it faster?")
Until next week,
-Nate
|
|
|
|