Thread: iterators and optimization

  1. #1
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300

    iterators and optimization

    If I'm iterating thru, eg, a 5000 member vector, is it worthwhile to do this:
    Code:
    vector<whatever>::iterator it = myvec.begin(), end = myvec.end();
    while (it != end) {
    rather than just
    Code:
    while (it != myvec.end()) {
    or will the compiler optimize this anyway? I would think since myvect could be shortened in the loop it cannot...
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  2. #2
    The larch
    Join Date
    May 2006
    Posts
    3,573
    The compiler can't optimize anything away arbitrarily, especially as you say that the loop will invalidate the end iterator. If that is the case, you can't use a cached end iterator in the first place.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  3. #3
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by anon View Post
    The compiler can't optimize anything away arbitrarily, especially as you say that the loop will invalidate the end iterator. If that is the case, you can't use a cached end iterator in the first place.
    Well, I meant in the case where I could (because I am not actually going to shorten anything, but the compiler cannot deduce that), is it worth it? I am presuming yes, but I thought I'd ask in case for some reason checking a value vs. returning one from a method here amounts to six vs two threes...
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  4. #4
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    If the one past the end iterator is not going to change, then it may be good to cache it in a variable that is declared constant just to document this fact, even if there is no measurable improvement in efficiency.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #5
    Registered User
    Join Date
    May 2009
    Posts
    242
    just on the basis of my pretty rudimentary understanding of how these iterators work, i would think assigning the value would almost have to be at least a little bit better.

    if it's at all reasonable in the specific case, though, i'd try converting it to
    Code:
    for_each(myvec.begin(), myvec.end(), myfunction);
    but maybe i'm just over-fascinated by some of the STL possibilities since I only recently started working with them.

  6. #6
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Aisthesis View Post
    if it's at all reasonable in the specific case, though, i'd try converting it
    I would look at it the other way around -- only use for_each if there is no other way, or it is significantly more convenient. I also imagine "for_each" is more intended for random access containers. Nb, it adds a functional call each time and is very unlikely to be more efficient than using iterators yerself.

    Always good to learn new things, but don't misconceive of their value just because they seem clever
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  7. #7
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by MK27
    I would look at it the other way around -- only use for_each if there is no other way, or it is significantly more convenient.
    A loop can always replace the use of std::for_each, so there certainly will never be "no other way". Even if it is convenient, it would be better to use another generic algorithm that better describes what is happening.

    Quote Originally Posted by MK27
    I also imagine "for_each" is more intended for random access containers.
    std::for_each just requires input iterators.

    Quote Originally Posted by MK27
    Nb, it adds a functional call each time and is very unlikely to be more efficient than using iterators yerself.
    If you are going to call a function that is not inlined anyway, then it would not make a difference. If you use a function object, the call might be inlined, and thus again it would not make a difference. What might be inconvenient is that you may need to define the function or function object yourself, and the logic contained in them is separated from the place where it is used (possibly just once). Unfortunately, we have to wait for lambda support or use non-standard libraries as a current workaround.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  8. #8
    The larch
    Join Date
    May 2006
    Posts
    3,573
    Until C++0x allows this at language level:

    Code:
    BOOST_FOREACH(whatever& we, myvec) { ... }
    Usually most convenient, however I couldn't tell if there might be a performance penalty.
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

Popular pages Recent additions subscribe to a feed