Re: iterator destructors
jrfaria@yahoo.com wrote:
I was profiling a piece of code that seemed pretty simple and
straightforward, but was not running as fast as I expected it too...
it turned out that the majority of the time(67%) was being spent on
the destructor of the iterator I used in a loop. This function is
called thousands of times for every frame(it's a plugin for a graphics
package) so I ended up replacing the vector<>::iterator with an int I
used to call the vector [] operator.
Ugly as it is, some modern processors are better at using a pointer/offset
operation than using a sliding pointer, which is why in tight loops this
might really be the faster choice.
That proved fine in speeding up code, but left me with a bad taste in
my mouth with regards to using iterators and the whole generic
programming thing...
Well, in most cases it should barely be noticeable, so that is no reason to
stop using iterators/algorithms.
does the iterator destructor really have that much work to do? Is that
a price you "have" to pay for using the stl algorithms? I'm using
STLport, by that way.
Unless you are using the special debug mode, the destructor should be a
no-op, as Doug already said. Other than that, I would be interested in the
code, the STLport version you are using and the target CPU.
Uli