STL Vectors VS. Standard Arrays
Author
Are STL Vectors slower than using standard arrays?
Ever since I found out about the vector container I have begun using them inplace of regular arrays. Is this wise in all cases?
I am just wondering because I have been using them to itterate thrugh vertexes in a 3D engine of mine. I want to know if this has any speed penalties.
thanx
Yargh, there was a very recent discussion on this right here:
The Thread
Go ahead and use std::vector.
The Thread
Go ahead and use std::vector.
The only speed penalties that I know of will be when you insert things at the beginning or in the middle of the vector, when you resize the vector (and cause it to have to reallocate space, which doesn't happen every time), or when you abuse passing vectors around as parameters, or returning them from functions, causing the vectors to have to be copied an unnecessary number of times (using references helps with this immensely). But once a vector is allocated, and once things are in them, then random access of its elements is just as quick as with an array (unless you use .at(), which adds a small overhead to make sure you're not accessing invalid elements).
From what I understand there is speed penalties if you randomly access something in the vector [as opposed to iterating through it].
But, as always, if you're not an expert programmer, you're likely going to write slow enough code that even those penalties won't matter much. Make it work, then worry about making it fast.
But, as always, if you're not an expert programmer, you're likely going to write slow enough code that even those penalties won't matter much. Make it work, then worry about making it fast.
Umm, random access is going to be as fast in release mode as it will end up as just a pointer addition (same as it is for regular arrays). The only exception to this is using the at method, which will have a slightly slower access time, as it does bounds checking.
Quote:Original post by Washu
Umm, random access is going to be as fast in release mode as it will end up as just a pointer addition (same as it is for regular arrays). The only exception to this is using the at method, which will have a slightly slower access time, as it does bounds checking.
Ah, thank you for the correction.
Quote:Original post by Agony
The only speed penalties that I know of will be when you insert things at the beginning or in the middle of the vector, when you resize the vector (and cause it to have to reallocate space, which doesn't happen every time), or when you abuse passing vectors around as parameters, or returning them from functions, causing the vectors to have to be copied an unnecessary number of times (using references helps with this immensely). But once a vector is allocated, and once things are in them, then random access of its elements is just as quick as with an array (unless you use .at(), which adds a small overhead to make sure you're not accessing invalid elements).
Since this thread compares vectors with raw arrays, this might be a good place to point out that arrays offer no functionality at all for inserting items at the beginning or in the middle, let alone resizing, and in order to do any of this, the programmer is going to have to do things very similar to what the STL maintainers are doing.
And as an addendum, if your doing enough inserts, etc. for it to be a problem then you should be using a container more appropriate to your needs (eg std::list).
really the only expense is the malloc'ing of new memory. If you want an STL compatable static array with bounds checking (optional), check out www.boost.org's array template class.
The std::vector<> is fine for many purposes. But unless you have a reason to change the number of elements, I would simply allocate an array dynamically. I only use std::vector<> when the amount of elements to be stored is either unpredictable, or can change during runtime. If you were to store a fixed number of vertices for a model, however, you really just should dynamically allocate an array.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
