4 ms·

I have done a lot of profiling work and I have observed similar things. One thing is const, another is virtual functions. A lot of people think they add overhea

I have done a lot of profiling work and I have observed similar things. One thing is const, another is virtual functions. A lot of people think they add overhead and avoid them for performance reasons but my profiling almost never showed them as a problem. Same for const and inline. it’s really hard to predict what the optimizer will do. Obviously there are stupid things that can be avoided from the start but in general I prefer clean code where people write for readability and simplicity and not speed.

EpicEng 7y ago
Yes, profile. Anecdotally, I once removed a number of virtual function calls as they were imposing significant overhead in a tight loop (image processing). Would that be the case today? No idea; I'd have to measure it again.
- Ididntdothis 7y ago
  Image processing is a different beast. A lot of subtle things are in play here. I remember getting big improvements by iterating through the images buffer either line vs row or even arranging memory in 64 byte squares instead of linear. I was often surprised when I looked at the optimized assembly. Optimizer are really clever and do a lot of surprising things....
  - EpicEng 7y ago
    Yes: row traversal (no hopping around in memory and causing cache flushes) and block size reads/writes are a big deal. Luckily they're easy enough to do right every time once you know. I used to take some flak from the "premature optimization blah blah" side of the house on occasion.
dbcurtis 7y ago
Inlining especially is call-site dependent. Little of the benefit of inlining comes from eliminating the call overhead on a modern processor. But quite often, functions are called with one or more parameters constant. So that enables a bunch of constant folding for that call site -- the compiler is good at noticing that if(1<7) is always going to be true, and dropping out the whole else branch, which can enable code motion and more common subexpressions... so inlining is often a win but often people misunderstand exactly why.
- rrss 7y ago
  "Inlining is a gateway drug^H^H^H^H optimization"

EpicEng 7y ago

Yes, profile. Anecdotally, I once removed a number of virtual function calls as they were imposing significant overhead in a tight loop (image processing). Would that be the case today? No idea; I'd have to measure it again.

Ididntdothis 7y ago
Image processing is a different beast. A lot of subtle things are in play here. I remember getting big improvements by iterating through the images buffer either line vs row or even arranging memory in 64 byte squares instead of linear. I was often surprised when I looked at the optimized assembly. Optimizer are really clever and do a lot of surprising things....
- EpicEng 7y ago
  Yes: row traversal (no hopping around in memory and causing cache flushes) and block size reads/writes are a big deal. Luckily they're easy enough to do right every time once you know. I used to take some flak from the "premature optimization blah blah" side of the house on occasion.

dbcurtis 7y ago

Inlining especially is call-site dependent. Little of the benefit of inlining comes from eliminating the call overhead on a modern processor. But quite often, functions are called with one or more parameters constant. So that enables a bunch of constant folding for that call site -- the compiler is good at noticing that if(1<7) is always going to be true, and dropping out the whole else branch, which can enable code motion and more common subexpressions... so inlining is often a win but often people misunderstand exactly why.

rrss 7y ago
"Inlining is a gateway drug^H^H^H^H optimization"