Sign in to follow this  

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.

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by JohnBolton
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.

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 this post


Link to post
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.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this