On 3/01/2011 22:34, Hexcoder wrote:
> The second step would be to get rid of hard coded limits where possible.

In the case of FixedSimpleVector, that's more difficult than it seems. The
hard-coded limit is needed because that class is explicitly designed to use
stack for storage, rather than the heap, which thus means the compiler
needs to know its size at build time.

This avoids the need to do heap allocation/frees (with the associated
locking), or re-sizes as the vector grows (which often, though not always,
requires a memcpy).

FixedSimpleVector is only used in places where either of those have a
drastic effect on performance. Going to a dynamic version of those classes
would require the use of a thread-local memory pool and smart management of
the amount of memory pre-allocated for the vector each time it's
instantiated (or analysis of the code that depends on it to see where we
can switch from using a vector to a list).

Also keep in mind that each time you increase the size, you're increasing
the amount of stack used for each level of recursion in a render.

-- Chris

Post a reply to this message