Say, I have a
std::vector v;
in my code and I need to access its elements very often in the program, looping them forwa
I had a test yesterday, use [] vs iterator, the code is create a vector with some elements and remove some elements from the vector. This is the code uses operator [] to access elements
TimeSpent([](){
std::vector<int> vt = { 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 };
for (int i = int(vt.size()) - 1; i >= 0; i--)
{
if (vt[i] % 2 == 0)
{
//cout << "removing " << vt[i] << endl;
vt.erase(vt.begin() + i);
}
}
});
The following code is about access vector elements by using iterator
TimeSpent([](){
std::vector<int> vt = { 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 };
for (std::vector<int>::iterator num = vt.begin(); num != vt.end();)
{
if (*num % 2 == 0)
{
num = vt.erase(num);
}
else
{
++num;
}
}
});
Tested by calling them by this function separately
void TimeSpent(std::function<void()> func)
{
const int ONE_MIL = 10000;
long times = ONE_MIL;
std::chrono::steady_clock::time_point start = std::chrono::steady_clock::now();
while (times > 0)
{
func();
--times;
}
std::chrono::steady_clock::time_point end = std::chrono::steady_clock::now();
cout << "time elapsed : " << std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count() << endl;
}
Tested environment is visual studio 2013 pro. version 4.5.51650
The results are :
operator[] : 192
iterator : 212
Summary: when we access the vector container, operator [] is faster than iterator.
A simple loop-based benchmark has been fulfilled. I used VS 2010 SP1 (release configuration).
In several billions of iterations the second approach turned out to be a bit faster, by 1%. The result (indices are slightly faster than iterators) is reproducible but the difference, as I said, is very small.
As always, it depends. Normally I wouldn't think you'd see any kind of difference, but only you can determine that by profiling your code. Some compilers implement vector iterators as raw pointers, and some don't. Also, in debug builds, some compilers may be using a checked iterator, which may be slower. But in production mode it may not be any different. Profile it and see.
In terms of speed, I think might be almost same. Better, you can profile and check anyway.
At least you can reduce the number of variables used :)
for( i = 0; i < size ; i++){
// some operations on v items
v[i];
v[size-i+1];
}
About const_iterator
: Pls refer my Q: Are const_iterators faster ?
I'd go for iterators, but what I would optimize is calling end()
in the loop and would change preincrement to postincrement. I.e. I'd
std::vector<SomeClass *> v;
std::vector<SomeClass *>::iterator i,ie;
std::vector<SomeClass *>::reverse_iterator j,je;
// i loops forward, j loops backward
for( i=v.begin(),ie=v.end(), j=v.rbegin(),je=v.rend(); i!=ie && j!=je; ++i,++j ){
// some operations on v items
}
And I don't think it's premature microoptimization, it's just writing better code. Much less evil than calling every attempt to write efficient code premature microoptimization and substituting thinking with profiling.