std::vector slowness

It's because you're in debug mode, and so it can't inline as well, meaning operator[] is quite possibly called as an actual function. Try testing those with debug mode OFF (and thus, optimizations on).

Unless, if you're doing std::vector< std::vector< uint32 > >, there will be some performance loss because each child vector has a seperate memory stash, requiring two offsets and a lookup instead of a single offset ( since texture[64][64] is really texture[64*64] in terms of memory allocation ).

Also, you'll have a minor preformance hit due to the fact that the memory of vector must be allocated dynamically, instead of on the stack. If the size of the array isn't going to change, boost::array might be a better choice. If you havn't allready done so, check out the rest of the Boost Libraries.

Do you create the vector every frame? Or empty it and re-fill it? Vectors provide functionality to grow and shrink as required, and that can consume CPU time. On the other hand, if you use a vector carefully (preallocating memory in advance, for instance) there's almost no reason why it would run slower than a normal array.

Quote:

Original post by Anonymous Poster Well I can think of only one additional reason... If the vector container has the texture rotated 90 degrees (compared to the layout of the static arrays), it might cache differently. But I have to admit that sounds a little far fetched.

Nope I made sure that in both cases, the pixels of the vertical stripes had successive memory locations.

It might also have to do with the fact that when I did it with std::vectors, those were part of a Texture class, while when I did it with the normal arrays, it were just global static arrays with a different index number for every texture.

So could the fact that it was part of a class be responsible for it?

Accessing a vector element should be slower than accesing an array because a vector is an object and you access it's elements through a method. It's beyond my knowledge if vectors are optimized by compilers to a point where they are as fast as a common array under any circumstance. I wouldn't rely on them if I needed speed tough.

Umm, these days, only an extremely bad compiler would not inline away calls to such trivial functions. Today's compilers do marvellous optimizations if you tell them to.

Quote:

Original post by owl Accessing a vector element should be slower than accesing an array because a vector is an object and you access it's elements through a method. It's beyond my knowledge if vectors are optimized by compilers to a point where they are as fast as a common array under any circumstance. I wouldn't rely on them if I needed speed tough.

Accessing a vector element should be exactly as fast as accessing an array element, since any sane compiler would inline std::vector::operator[](), and vectors have a contiguous memory layout, just like arrays—in effect, once compiled (unless in debug mode/with optimisations disabled), a vector element lookup is an array element lookup.

Quote:

Original post by Miserable Quote: Original post by owl Accessing a vector element should be slower than accesing an array because a vector is an object and you access it's elements through a method. It's beyond my knowledge if vectors are optimized by compilers to a point where they are as fast as a common array under any circumstance. I wouldn't rely on them if I needed speed tough. Accessing a vector element should be exactly as fast as accessing an array element, since any sane compiler would inline std::vector::operator[](), and vectors have a contiguous memory layout, just like arrays—in effect, once compiled (unless in debug mode/with optimisations disabled), a vector element lookup is an array element lookup.

Couldn't it throw exceptions at some point that could slow down the app? Like out_of_range or etc?

std::vector::operator[]() doesnt throw and does no bounds checking, you are thinking of std::vector::at() which does bounds check and can throw exceptions

You might want to check out vector::reserve.

Kind regards.

Mark Coleman