[Dcmlib] std::map vs std::hash_map

[Mathieu Malaterre]

Sean,

	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:

union {
    uint32_t tagkey
    uint16_t tab;
}

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,
Mathieu
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.
> 
> -Sean
> 
> Mathieu Malaterre wrote:
> 
>>Ok guys,
>>
>>    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.
>>
>>
>>Mathieu
>>_______________________________________________
>>Dcmlib mailing list
>>Dcmlib at creatis.insa-lyon.fr
>>http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
>>
>>
>>
> 
> _______________________________________________
> Dcmlib mailing list
> Dcmlib at creatis.insa-lyon.fr
> http://www.creatis.insa-lyon.fr/mailman/listinfo/dcmlib
>