Re: Fastest way to clone a hash_map
On 29 Apr., 20:09, devdude <rottygu...@yahoo.com> wrote:
I have the need to take a snapshot of a hash_map during execution
(actually transform it to a vector). This map is a shared resource
and therefore must be locked prior to any read/write operations thus I
need to minimize the amount of time the map resource is locked.
The map is defined as type <string, boost::shared_ptr<myobject>>. My
algorithm is as such:
void SnapShotToVector( vector< pair< string,
boost::shared_ptr<myobject> >& vec )
This member function could be const, I guess.
{
lockResource(this->map);
vec.resize( map.size() );
copy(this->map.begin(), this->map.end(),list.begin());
^
Don't you mean here vec instead of list?
unlockResource(this->map);
}
For about 3M elements w/in the map, I'm noticing that the resize op
takes about 150ms and the copy takes ~850ms. Is there any way to do
better? I suppose the total time doesn' t matter as it's the time the
resource is actually locked is the primary concern.
1) The thread title emphasizing on 'cloning' is
IMO a misnomer, given that you do not perform
a pure element-wise cloning (in the sense of deep
copy) at all - you seem to accept a 'flat' shared_ptr
copying.
2) The most natural "cloning" given your source and
destination containers seem to be to replace the lines
vec.resize( map.size() );
copy(this->map.begin(), this->map.end(),vec.begin());
by
typedef vector<pair<string, boost::shared_ptr<myobject> > > VecType;
VecType(this->map.begin(), this->map.end()).swap(vec);
which - just by chance - also provides one higher level
of transaction-safety free of charge ;-). Whether this
approach is more efficient than your original one can
only be found out by testing with a given compiler,
standard library and a proper set of compiler flags.
3) Your locking/unlocking strategy looks suspicious
to me, because it is not exception-safe. You should
definitively use an RAII-helper to guarantee the final
unlocking.
4) I don't understand what you mean with this:
"I suppose the total time doesn' t matter as it's the
time the resource is actually locked is the primary concern"
Why does the total time not matter, if the locking-time
is of primary concern??
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]