//Bind the texture
glBindTexture(blah blah, materialsVector[materialID].textureID);
//effects
if(materialsVector[materialID].transparent)
// Do transparent code
//render
std::vector performance question
Author
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:
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:
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.
Material &material = materialsVector[materialID];glBindTexture(blah blah, material.textureID);if (material.transparent) // do somethingSince 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.
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
