[Dcmlib] std::map vs std::hash_map
mathieu.malaterre at kitware.com
Tue Jul 5 20:34:32 CEST 2005
Good catch ! the problem was indeed the hash function. I replaced my
hash function with a sscanf on a TagKey to retrieve the DICOM
group/element. But then most of the time was spent in the sscanf (this
function is soooo slow). So I change the typedef TagKey to be a:
There are still some glitch, but the improvement now is 23% (in fact
most of the improvement is due to the union vs std::string).
Thanks for your comments,
Ps: I'll keep investigating
Sean McInerney wrote:
> Hi Mathieu,
> A 5% improvement is surprisingly weak, but may be due to the typical key
> sizes found in a DICOM table as well as the size of the table. Depending
> on the hash function used, you may have a lot of collisions and multiple
> rehashing necessary for any given key. If you really *need* better
> performance, you may want to investigate passing a different hash
> function (functor) as a template parameter to std::hash_map tuned for
> your specific distribution of input values (keys).
> Or better yet, skip the enormous time sink of tweaking your hash
> implementation and enjoy the handy lexicographic sorting offered by
> std::map. By definition, hash maps have no such ordering.
> Happy 4th of July to all ... especially the French members of the list.
> We would not be here without you. Sorry to have made such a mess of the
> place in the meantime, we'll try to fix it up in the near future.
> Mathieu Malaterre wrote:
>> I did perform a few bench comparing in Release mode on linux debian,
>>gcc 3.3. If I replace the TagKeyHT from a std::map to a
>>std::hash_table.. I only get a ~5% improvement. But again to reach 5%
>>improvement I was parsing (see TestAllPrint.cxx) all files from gdcmData
>>and all files from gdcmSampleData (rsync serveur). Basically the
>>difference between a map and a hash is extremely negligeable. You only
>>notice it when you parse a lot of file and a lot of tags...
>> Since this is not exactly what I expected I'll differ the merge with
>>my local change until I found a more drastic change that affect the
>>speed of gdcm.
>> Unless of course people are interested in the patch right away...
>> My machine: CHIRON, which used to do the win32 part (bcc32, and
>>vs7.1) died last week (I am guessing the power supply), so it will only
>>be back middle of next week.
>>Dcmlib mailing list
>>Dcmlib at creatis.insa-lyon.fr
> Dcmlib mailing list
> Dcmlib at creatis.insa-lyon.fr
More information about the Dcmlib