Re: Don't pass by reference to non-const?
On May 9, 12:59 am, Ian Collins <ian-n...@hotmail.com> wrote:
On 05/ 9/10 11:39 AM, Thomas J. Gritzan wrote:
Am 08.05.2010 17:43, schrieb Balog Pal:
"James Kanze"<james.ka...@gmail.com>
[...]
std::vector<double> v(...);
for (... lot's of iterations ... )
{
// calculate some values based on the current contents
// of v.
some_function(&v, ... the calculated values ...);
// ...
}
In this example you clearly use the vector as INOUT
parameter, and have a performance gain from that fact.
Originally we were talking about OUT parameters...
No. The performance gain comes from the fact that he only
allocates memory once and uses this memory for all
iterations. It's the same with std::getline (in a loop),
where the output string's capacity grows to the maximal line
length at some time, and then there's no more allocation
unless you copy the strings.
That is true, but it's interesting how close the two
approaches are in performance when that factor is removed.
Comparing case 1:
std::vector<std::vector<double> > v(loops);
for( int n = 0; n < loops; ++n )
{
fn1(v[n]);
double d = v[n][4999];
}
with case 2:
std::vector<std::vector<double> > v(loops);
for( int n = 0; n < loops; ++n )
{
v[n] = fn2();
double d = v[n][4999];
}
Where f1 and f2 are:
void fn1( std::vector<double>& v ) {
for( int i = 0; i < 1000000; ++i ) v.push_back( 42.0*i );
}
That's not quite the same thing. A closer approximation would
be something like:
std::vector<double> f1()
{
std::vector<double> retval;
for ( int i = 0; i < 1000000; ++i ) v.push_back( 42.0 * i );
return retval;
}
void f2( std::vector<double>& retval )
{
retval.clear();
for ( int i = 0; i < 1000000; ++i ) v.push_back( 42.0 * i );
}
or even:
void f2( std::vector<double>& retval )
{
assert( retval.size() >= 1000000 );
for ( int i = 0; i < 1000000; ++ ) v[i] = 42.0 * i;
}
Where f1 or f2 is called in a loop (and in the case of f2, the
definition of the vector is outside of the loop).
std::vector<double> fn2() {
std::vector<double> v;
for( int i = 0; i < 1000000; ++i ) v.push_back( 42.0*i );
return v;
}
I see 3.73 seconds for case 1 and 4.07 seconds for case 2.
The issue isn't as clear cut as that, even in your example. In
a real program, for example, using push_back each time on a new
vector will result in more allocations, and possibly (probably?)
more fragmentation.
Anyway, the fact is that we originally used the "natural"
version, returning the vector, that the program was too slow,
that one of the changes we tried was passing the vector as an
out parameter, and that it made a significant difference.
And that the compiler we were using did RVO (both named and
unnamed), but that the context we we working in didn't allow it.
(IIRC, the vector was part of a larger struct.)
--
James Kanze