3 ms·

Try building the performance critical sections with release settings in debug builds and have a seperate "slow debug" version which doesn't. Its not a magic bul

by jheriko 16y ago

Try building the performance critical sections with release settings in debug builds and have a seperate "slow debug" version which doesn't. Its not a magic bullet that will make debug as fast as release, but it can usually bring debug framerates to acceptable levels whilst letting you use the debugger on whatever you are working on most of the time (unless you are trying to fix some core engine bug etc...)

malkia 16y ago
There are no performance critical sections with RVALUES - it's everywhere - it's not isolated. It's not like here is the skinned code on CPU using SSE2, and here is the video decoder, and here is the this and that. The same effect have the overloaded math operators. Yes they are inlined expanded in release (-O9 if you will), but usually not (unless explicitly specified) in debug. So once you start using them more and more, every even simple math operation becomes function call (in debug), to a point where I have seen 6x slowdown (in one of our heavily templated math libraries - that had many types of vectors - direction, position, normal, etc (depending on it's contents, but still all of them 3 or 4 dimensions), and many types of 4x4 and 3x4 matrices (diagonal, LU, identity, etc.). It required so much to type in the interface in the function, that it was heavy burden on the programmer. I much prefer simple float* or double* (or both), rather than some obscured DirectionVector3, or PositionalVector3, DiagonalMatrix44, and such. We are so much led to believe that if we give the compiler the best instructions it'll help us, that we forget that what helps the compiler in this case hurts us as programmers. It's the compiler that should be figuring out these things, not us. And if it can't, then we better find some compromise.

3 ms·

Try building the performance critical sections with release settings in debug builds and have a seperate "slow debug" version which doesn't. Its not a magic bul

by jheriko 16y ago

malkia 16y ago
There are no performance critical sections with RVALUES - it's everywhere - it's not isolated. It's not like here is the skinned code on CPU using SSE2, and here is the video decoder, and here is the this and that. The same effect have the overloaded math operators. Yes they are inlined expanded in release (-O9 if you will), but usually not (unless explicitly specified) in debug. So once you start using them more and more, every even simple math operation becomes function call (in debug), to a point where I have seen 6x slowdown (in one of our heavily templated math libraries - that had many types of vectors - direction, position, normal, etc (depending on it's contents, but still all of them 3 or 4 dimensions), and many types of 4x4 and 3x4 matrices (diagonal, LU, identity, etc.). It required so much to type in the interface in the function, that it was heavy burden on the programmer. I much prefer simple float* or double* (or both), rather than some obscured DirectionVector3, or PositionalVector3, DiagonalMatrix44, and such. We are so much led to believe that if we give the compiler the best instructions it'll help us, that we forget that what helps the compiler in this case hurts us as programmers. It's the compiler that should be figuring out these things, not us. And if it can't, then we better find some compromise.