Not really a rebuttal. There's a lot of low hanging fruit in code bases were you can read code and see what's making things slow. Like the parent comment stated, you can visually tell if there's a lot of allocations in a certain part, and easily see if those allocs are present in a loop and often reason simply how many times that loop can be called.
I can see in the code when data layouts aren't optimal, and fix that.
There's a lot of optimizations that need more of a deep dive, but you can get a lot of gains by just reading and reasoning about your code/data.
EDIT: To add, there are cases were you specifically can't read code and understand performance issue, but you should first ask, is that because you just don't understand the APIs/Libs/tools you're using, or is it fundamentally difficult. For example, often at work I see people complain about their torch code being slow and needing to bust out a profiler, but often those people just don't understand how tensor operations work internally so of course they can't reason about the code and see the way they're using the lib is suboptimal.
That these performance hogs were in production reinforces my point that you can't spot slow code just by looking at it, unless you already know that it's slow.
I even have an example myself, but I'm not sure I can share it in detail. It was a common idiom that was used throughout the code. After tracing a performance problem to a specific function, it was immediately obvious to me that the common idiom was the problem in this function, and how to fix it very easily. But only because I traced a performance problem to this function. Otherwise I would have skimmed over it.
Are you serious? Of course you can. Some hash algorithms are slower than others, you can read that and know that. Allocating in a hot loop is probably slower than allocating outside of it. Duh? I can't believe this even has to be justified, of course you can look at code and get an idea of its performance properties lol
Obviously you want empirical evidence to justify changes, but like... duh, you can read code and understand how it executes.
Sometimes when you look at code you know is slow, you can immediately see why it's slow. Obviously you didn't see it when you wrote it, which disproves your hypothesis.
What? Sorry, I genuinely have no idea what you're talking about. Is it possible to look at code and intuit, just by reading, how to speed it up? Duh, yes. If you disagree, lol.
Keep in mind that I've never stated that all performance issues are findable through code review. Just that there are many that are.
> You can very easily spot performance issues through code.
If you think that this is false, there's literally nothing you can contribute.
I can't take this seriously. The claim "you can look at SOME code and see how to optimize it" is trivially true, and saying "you can't look at ALL code and see how to optimize it" changes nothing.
Exactly, you have to find the slow code first, with profiling, and then sometimes it is obvious why that code is slow. It is unlikely you can just look at a project and find the slow code in it.
You absolutely can. I've given enough examples that are obviously true. If you can't read code and reason about its performance, that is a personal issue.
