# std::vector performance question

This topic is 3661 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

This is currently how I'm handling textures/materials in my game. I have an std::vector of my materials. Materials have a texture ID (OpenGL). So any group of polygons with a certain material has a material ID and accesses material information through the vector. So when rendering it looks something like this:
//Bind the texture
glBindTexture(blah blah, materialsVector[materialID].textureID);

//effects
if(materialsVector[materialID].transparent)
// Do transparent code

//render

Hopefully you understand what I'm trying to say. My question: Is this terribly slow? I'm just a little hesitant to be reading from a std::vector multiple times every frame. What are some other methods of doing this?

##### Share on other sites
If you are really worried about the performance, you will cache a reference to the material for the duration of the function, something like this:
Material &material = materialsVector[materialID];glBindTexture(blah blah, material.textureID);if (material.transparent) // do something

Since a std::vector is just an object-oriented wrapper around a native C++ array, it wont be any slower than a native array, and each index costs a pointer addition followed by a dereference, as opposed to just a dereference if you cache the reference as I show.

##### Share on other sites
Accessing an element in a vector will probably take less than 0.01% of the time of the glBindTexture call and less than 0.00001% of the rendering code inside the if () {...}. Actually, those are total guesses and I suspect they are too high.

Let's assume that accessing an element in a vector takes 100 CPU cycles (it really probably only takes 3 or 4). Then on a 3 GHz processor, the number of accesses that would take 1% of a frame at 60 fps is 5,000. If you are doing 5,000 accesses per frame, then there might be a very small reason for considering the speed of vector access. Note: These times assume no cache misses.

Finally, code accessing an element in a vector is likely to be compiled into the same machine code as accessing an element in a C array. In other words, there is no difference.

I hope these convince you that you don't need to worry about difference in the speed of std::vector accesses as compared to standard C array accesses. However, the real answer is that in order to get a definitive answer about what is fast and what is slow, you must profile the code. Fsst and slow are hard to determine for the general case.

##### Share on other sites
Awesome. That answers my question. Thanks

##### Share on other sites
Quote:
 Original post by JohnBoltonAccessing an element in a vector will probably take less than 0.01% of the time of the glBindTexture call and less than 0.00001% of the rendering code inside the if () {...}. Actually, those are total guesses and I suspect they are too high.Let's assume that accessing an element in a vector takes 100 CPU cycles (it really probably only takes 3 or 4). Then on a 3 GHz processor, the number of accesses that would take 1% of a frame at 60 fps is 5,000. If you are doing 5,000 accesses per frame, then there might be a very small reason for considering the speed of vector access. Note: These times assume no cache misses.

Speculation on the percentage of frame time spent accessing a vector is completely meaningless, and beyond that, cycle counts are a lousy way to regard code execution speed on a modern, pipelined RISC machine (i.e a standard intel CPU), let alone off-the-top-of-your-head estimates.

The rest of your post is pretty much correct though.

##### Share on other sites

This topic is 3661 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628645
• Total Posts
2984023

• 9
• 9
• 9
• 10
• 21