perfomance of clear vs swap

[Krishanu Debnath]

Hello,

I have a call to hash_map::clear () function which takes long time.

someClass::some Function()
{

// typedef hash_map<name_i d, uintMp;
// Mp p;
// assuming proper namespace, hash function for name_id obj.

p.clear();
}

Above p.clear() takes long time, profiling indicates 'number of bucket
of hash table is large'.

Now, just for sake of experiments, I replaced this 'clear' call with
swap. i.e.

someClass::some Function()
{

// typedef hash_map<name_i d, uintMp;
// Mp p;
// assuming proper namespace, hash function for name_is obj.

//p.clear();
Mp tmp;
p.swap(tmp);
}

Now runtime drops significantly, 10 fold less.

What's exactly cause this run time reduction?

Thanks,
Krishanu


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Noah Roberts]

Krishanu Debnath wrote:

Hello,

I have a call to hash_map::clear () function which takes long time.

Hmmm...surprise d this made it into moderated. I've taken it out as I
don't like to wait.

hash_map is not standard and is different on every implementation that
implements it. It's hard to say what the reduction in speed is caused
by.

[mlimber]

Noah Roberts wrote:

Krishanu Debnath wrote:

Hello,

I have a call to hash_map::clear () function which takes long time.

Hmmm...surprise d this made it into moderated. I've taken it out as I
don't like to wait.

hash_map is not standard and is different on every implementation that
implements it. It's hard to say what the reduction in speed is caused
by.

But it is part of TR1 as std::tr1::unord ered_map, which qualifies under
FAQ 5.9.

Cheers! --M

[mlimber]

Krishanu Debnath wrote:

I have a call to hash_map::clear () function which takes long time.

someClass::some Function()
{

// typedef hash_map<name_i d, uintMp;
// Mp p;
// assuming proper namespace, hash function for name_id obj.

p.clear();
}

Above p.clear() takes long time, profiling indicates 'number of bucket
of hash table is large'.

Now, just for sake of experiments, I replaced this 'clear' call with
swap. i.e.

someClass::some Function()
{

// typedef hash_map<name_i d, uintMp;
// Mp p;
// assuming proper namespace, hash function for name_is obj.

//p.clear();
Mp tmp;
p.swap(tmp);
}

Now runtime drops significantly, 10 fold less.

What's exactly cause this run time reduction?

I'm not sure why this would be. Are you using SGI's hash_map extension
(which is similar to std::tr1::unord ered_map)? Are you measuring the
performance of the entire function including the destructors for
automatic objects like tmp?

Cheers! --M
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Noah Roberts]

mlimber wrote:

Noah Roberts wrote:

Krishanu Debnath wrote:

Hello,
>
I have a call to hash_map::clear () function which takes long time.

Hmmm...surprise d this made it into moderated. I've taken it out as I
don't like to wait.

hash_map is not standard and is different on every implementation that
implements it. It's hard to say what the reduction in speed is caused
by.

But it is part of TR1 as std::tr1::unord ered_map, which qualifies under
FAQ 5.9.

But hash_map is not unordered_map. Read the first part on unordered
containers in TR1 that explains exactly why the name hash_map was _not_
used....because that name is already taken in most implementations by
incompatible and disparate versions of a hash interface.

I doubt that is the topic of discussion or the OP probably would have
used the TR1 name. More likely they are working with some
implementation defined interface.

[Krishanu Debnath]

mlimber wrote:

Krishanu Debnath wrote:

>I have a call to hash_map::clear () function which takes long time.

someClass::som eFunction()
{

// typedef hash_map<name_i d, uintMp;
// Mp p;
// assuming proper namespace, hash function for name_id obj.

p.clear();
}

Above p.clear() takes long time, profiling indicates 'number of bucket
of hash table is large'.

Now, just for sake of experiments, I replaced this 'clear' call with
swap. i.e.

someClass::som eFunction()
{

// typedef hash_map<name_i d, uintMp;
// Mp p;
// assuming proper namespace, hash function for name_is obj.

//p.clear();
Mp tmp;
p.swap(tmp);
}

Now runtime drops significantly, 10 fold less.

What's exactly cause this run time reduction?

I'm not sure why this would be. Are you using SGI's hash_map extension

Yes. I am using g++ 4.0.2, which adopts SGI's implementation, I believe.

(which is similar to std::tr1::unord ered_map)? Are you measuring the
performance of the entire function including the destructors for
automatic objects like tmp?

Yes.

Krishanu
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[mlimber]

Noah Roberts wrote:

mlimber wrote:

Noah Roberts wrote:

Krishanu Debnath wrote:
Hello,

I have a call to hash_map::clear () function which takes long time.
>
Hmmm...surprise d this made it into moderated. I've taken it out as I
don't like to wait.
>
hash_map is not standard and is different on every implementation that
implements it. It's hard to say what the reduction in speed is caused
by.

But it is part of TR1 as std::tr1::unord ered_map, which qualifies under
FAQ 5.9.

But hash_map is not unordered_map. Read the first part on unordered
containers in TR1 that explains exactly why the name hash_map was _not_
used....because that name is already taken in most implementations by
incompatible and disparate versions of a hash interface.

Right, but it is also similar enough to the TR1 container to fall
within the bounds of this group, IMHO (and apparently in that of the
moderator of c.l.c++.m). This question may simply be a QOI issue for a
container that is quite close to TR1's, or it may be an issue of misuse
of the container or faulty measurements. In any of these cases, at
least initially I think it is falls within the (fuzzy) boundaries for
this group, whereas if it is an issue of a non-standard container that
is unlike unordered_map but with the same name, then it is almost
certainly outside the bounds of this group. Given the information in
the OP, however, I don't think we can determine for certain which of
these it is, and so ISTM that we should give it the benefit of the
doubt.

Cheers! --M

[Aaron Graham]

I have a call to hash_map::clear () function which takes long time.
[...]

Now, just for sake of experiments, I replaced this 'clear' call with
swap.

[...]

Now runtime drops significantly, 10 fold less.
What's exactly cause this run time reduction?

Because the two functions do different amounts of work.

clear() requires time that is linear with respect to the number of
elements in the container. Destructors are called, memory is
deallocated, etc. But swap() can be done by swapping a few pointers.

Aaron
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]

[Noah Roberts]

Aaron Graham wrote:

I have a call to hash_map::clear () function which takes long time.

[...]

Now, just for sake of experiments, I replaced this 'clear' call with
swap.

[...]

Now runtime drops significantly, 10 fold less.
What's exactly cause this run time reduction?

Because the two functions do different amounts of work.

clear() requires time that is linear with respect to the number of
elements in the container. Destructors are called, memory is
deallocated, etc. But swap() can be done by swapping a few pointers.

Yes, but it seems that swapping with an empty temporary and then
deleting it would also call the same destructors and such that clear
would.

[Seungbeom Kim]

Aaron Graham wrote:

>I have a call to hash_map::clear () function which takes long time.

[...]

>Now, just for sake of experiments, I replaced this 'clear' call with
swap.

[...]

>Now runtime drops significantly, 10 fold less.
What's exactly cause this run time reduction?

Because the two functions do different amounts of work.

clear() requires time that is linear with respect to the number of
elements in the container. Destructors are called, memory is
deallocated, etc. But swap() can be done by swapping a few pointers.

That's true for swap() alone, but what about the destructor of the
"temporary" variable (tmp in the OP's code) when it goes out of scoppe?
Doesn't it do the same things, including destruction and deallocation?

--
Seungbeom Kim

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.m oderated. First time posters: Do this! ]