Re: Do I really have to use an array?
On Jan 26, 4:18 am, mike3 <mike4...@yahoo.com> wrote:
On Jan 25, 6:41 am, James Kanze <james.ka...@gmail.com> wrote:
On Jan 25, 1:38 am, Salt_Peter <pj_h...@yahoo.com> wrote:
On Jan 24, 3:15 pm, mike3 <mike4...@yahoo.com> wrote:
Your code uses integer everywhere instead of std::size_t
(or size_type) to track length.
Could these conversions actually cost as much as the entire
multiplication
loop?
Which loop? Does a conversion cost nothing? no.
It depends on which conversion. Conversions between integer
types, or between pointers, as long as no multiple inheritance
or virtual base classes are involved, typically have no runtime
cost.
I'm trying to figure out how you are 'managing' your elements,
i see a std::vector of pointers and std::auto_ptrs that are
being released() to transfer ownership. Thats very strange to
say the least. Any reason you aren't using boost::shared_ptr?
Those are copyable and assignable.
But copying them and assigning them has a very definite runtime
penalty. Not usually an issue, but since he's addressing a
performance problem.
There is one case where std::vector is significantly slower than
an array: creation and destruction. If he's creating a lot of
small, short livedvectors, that couldslowthings down. As an
alternative to array, he might want to look into boost::array.
That's what the point of the vector stack was: to avoid having to keep
creating vectors. It would set up a pile of them that could then be
popped off as needed. Once there's enough for all the threads, no
more are created. They're just pushed/popped on/off the stack.
I'd have to see the code, but if the stack itself is based on
the STL, you may simply have some deep copies in there. Which
is likely to be even slower than constructing a new vector each
time around.
It's just a hunch, of course. What you really should do is see
where the profiler says you're spending your time. If it's in
the allocator of vector, then there's probably something you
can do about it. If not, I doubt that the problem is vector
itself.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34