Sign in to follow this  

which is faster?

This topic is 4336 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

for (int i = 0; i < myVec.size(); ++i)
    myVec[i]->DoSomething();
or
vector<myClass*>::iterator iObject;
    for (iObject = myVec.begin(); iObject != myVec.end(); iObject++)
        (*iObject)->DoSomething();
also, does anyone know if there's a faster way to render with gdi than using BitBlt() ?

Share this post


Link to post
Share on other sites
First of all, your post-increment in the second section could generate an unused temporary object, but all the big-name compilers will optimise that away. I've read that dereferencing a pointer can be costly in cache misses, but I'm going to again go with the compiler optimising that sort of thing away (in your very basic example).

Share this post


Link to post
Share on other sites
This is a case of "Premature Optimization"; the compiler will figure out the way that's the fastest for you here, and will probably compile down to something closer to the first one, even though the second one is generally preferred due to readability concerns.

edit: and yeah, like ^^ he said, you really need to pre-increment the iterator.

So, pick one and keep coding.

Share this post


Link to post
Share on other sites
Quote:
Original post by zappernapper

for (int i = 0; i < myVec.size(); ++i)
myVec[i]->DoSomething();

or

vector<myClass*>::iterator iObject;
for (iObject = myVec.begin(); iObject != myVec.end(); iObject++)
(*iObject)->DoSomething();

for_each(myVec.begin(), myVec.end(), mem_fun(&myClass::DoSomething));

That's precisely the problem with premature optimization. You're so focused on making something fast that you don't check to see if you could make it better first - more compact, easier to understand, etc.

Share this post


Link to post
Share on other sites
the example w/ the iterator is something i got out of a book. i prefer to use the for loop and increment a counter b/c that looks cleaner than creating an iterator. i always wondered how specifically to use for_each, i think i will try that, so thanx!

Edit: it just goes to show you, there's always SOMETHING in the STL that you've never seen b4 (mem_fun()), oh and i didn't think i was being premature, i have the game all written and was running my profiler, and wanted to tweak the time spent rendering

Share this post


Link to post
Share on other sites
Quote:
Original post by zappernapper
oh and i didn't think i was being premature, i have the game all written and was running my profiler, and wanted to tweak the time spent rendering


Ok, it weren't premature just stupid. Also I think you should change main(char** argv,int argc) to main() because you need your program to be faster. If you have profiled and you are sure that specific loop is the problem, just TRY changing it run it through the profiler and look how you have gained 1-5 cycles. If such a loop is actually your bottleneck I'm sure you should optimize DoSomething instead of the loop itself. This is like changing 1.0f to 1.0F to get a better performance.

Share this post


Link to post
Share on other sites
Quote:
Original post by Oluseyi
Quote:
Original post by CTar
Ok, it weren't premature just stupid.

Hey! I do the irrational and indiscriminate insulting around here, got that?! Now apologize to the gentleman!

I don't like your face. [grin]

[Edited by - Rebooted on January 29, 2006 8:10:14 AM]

Share this post


Link to post
Share on other sites
Quote:
Original post by Oluseyi
Quote:
Original post by CTar
Ok, it weren't premature just stupid.

Hey! I do the irrational and indiscriminate insulting around here, got that?! Now apologize to the gentleman!

Ok, I'm sorry[grin]. Anyway my post might have seemed a little harsh, but I'm just trying to tell you that there is a very little chance that you should worry about this. I would personally prefer the latter for two reasons, it's easier to understand and you can change the container type without breaking the loop (std::list for example doesn't have the [] operator).

Also in some special containers operator[] might be implemented in O(n) (for example in std::slist if it had an operator[]) or something like that, here iterators will be an advantage since it will be able to choose the best way to access the data.

Share this post


Link to post
Share on other sites
yeah, but i don't like lists :) and it seemed to run a bit better using []. at any rate using for_each was a horrible idea in this instance because i had to call bind2nd() to use it with an argument and that function liked to take its time. I realize that changing DoSomething() (incidentally should really be called something like Render() ) is the ideal approach, that's y in my original post i asked if anyone knew a faster way to draw besides using BitBlt and TransparentBlt, i'm only using the gdi, gdi+ APIs.

Share this post


Link to post
Share on other sites
Quote:
Original post by zappernapper
yeah, but i don't like lists :) and it seemed to run a bit better using []. at any rate using for_each was a horrible idea in this instance because i had to call bind2nd() to use it with an argument and that function liked to take its time.

I'd use boost/std::tr1 bind. And what do you mean it "liked to take its time"? bind2nd() won't result in any performance overhead.

Share this post


Link to post
Share on other sites
Quote:
Original post by zappernapper
this function is my rendering function, so it's getting called the most, and according to my profiler it was eating up a lot more time than any of my other functions


You should almost certainly instead focus on the contents of DoSomething(), rather than the iteration, then. Or perhaps on figuring out how you might get away with having fewer things to DoSomething() upon. Or on not DoSomething()ing every object every time.

Share this post


Link to post
Share on other sites

This topic is 4336 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this