1. Quick Question about the Efficiency of the STL

Hi,

Suppose I have the following code segment:

Code:
```std::vector<float> X(5, 1.0);
std::vector<float>::iterator IterX;
for(IterX = X.begin(); IterX != X.end(); IterX++) {
std::cout << *Iter << " ";
}```
and the following code segment:

Code:
```std::vector<float> X(5, 1.0);
for(int i = 0; i < 5; i++) {
std::cout << X.at(i) << " ";
}```
Which segment would be more efficient in terms of performance? I don't know how at() is implemented in the STL, but my guess would be that each time at() is called, the compiler internally creates an interator and iterates it the required number of times before dereferencing it. But I am not sure, because the book I am reading does say that std::vector<> provides fast random access to its elements.

*****

Note: this is not homework! I am not in school.

2. My guess is it depends on the implementation. You can actually test this if you create big enough containers

3. A vector uses contiguous memory, so the at probably just uses the index multiplied by the size of the type to figure out how far in memory to go. The iterator implementation probably includes a pointer that is incremented each time.

The at() might also be slower due to range-checking, although you could ask the same question about operator[] versus an iterator to avoid the range-checking complication.

Bottom line is that it really depends on the implementation (except for the range-checking part), so you should do timing tests on your platform if you really need to know. In reality it probably doesn't matter at all. I would use the iterator in case I decided to change the container to something else later.

4. http://www.sgi.com/tech/stl/complexity.html
A lot of the STL has statements about how complex (in relative terms) various actions are.

5. I have found STL to be very fast as long as you do not do a lot of inserting, sorting, etc. So far my system is handling 12500 trees in a vector, rendering terrain with shaders, and a load of other tasks and I still get over 250 FPS.

For the power it brings, STL is definitely worth the very small performance hit.

6. If your STL implementation happens to cache it's size, you're in luck, all you need to worry about would be the processor pipelining the wrong set of instructions in the range checking code.

I'm guessing iterators are faster; with subscripts you may need to do a multiplication (or at least, a shift) for each access, while iterators (if using pointers) will only require an increment (ie. an addition).

It is possible to optimize the iterator version by caching the end of the array in a second iterator; how much performance benefit this will bring is beyond me.

7. >but my guess would be that each time at() is called, the compiler internally
>creates an interator and iterates it the required number of times before dereferencing it.
Why would it do that when a simple range check is sufficient?
Code:
```reference at ( size_type sub )
{
if (sub < 0 || sub >= size() )
throw out_of_range ( "Invalid subscript" );

return (*this)[sub];
}```

8. Originally Posted by Prelude
Why would it do that when a simple range check is sufficient?
Or an even simpler check? (size_type is required to be unsigned)
Code:
```reference at ( size_type sub )
{
if (sub >= size() )
throw out_of_range ( "Invalid subscript" );

return (*this)[sub];
}```

9. >(size_type is required to be unsigned)
Gah! Brain fart. Thanks for the correction.