[ODE] Re: Capped Cylinder - trimesh collider - FIXED!!!

[Russ Smith]

hi nguyen,

> Hmm...! Could you please explain? I do think that inline
> is good for small function.

inline functions should be treated as optimizations, for all but the
smallest and most trivial functions. in other words, you should
determine that a function should be inlined only after performance
testing, profiling etc - typically when the code is stable, not during
development. the trouble with inline functions is that they can make the
code bigger, which in itself can greatly hurt performance because it
causes other code to be deleted from the I-cache. i have seen even
small, simple code grow to hundreds of k in size just by indiscriminate
use of inline functions.

> ADM> 3) Stylistically it hurts to see so many globals... I don't
> ADM> really know what to say about that.
>      Yes, I don't like it either. But I don't see any other way to get
>      through though. Moreover, I just focus on the performance side of
>      the code and globals don't hurt performance...

globals are bad for two reasons. first, they usually prevent the code
from being thread-safe. i don't know of anyone using ODE in multiple
threads, but there shouldn't be anything in the library that precludes
this. second, globals DO hurt performance, in two ways: (1) they are
harder for the compiler to optimize with because less can be
determined about aliasing to globals, and (2) globals are typically not
stored anywhere near the stack, so you get less locality of reference
(remember that the stack is a hot area of the D-cache, so changing a
global to a stack variable can often save cache-load cycles).
if you have a bunch of state that must be passed between functions, just
put it all in a stack (if not too large) or heap structure and pass the
pointer around.

BTW, thanks for all the hard work!

russ.

-- 
Russell Smith
http://www.q12.org