On 11/12/05, Robert Ramey <ramey@rrsd.com> wrote: [snip - Martin Slater wrote]
A couple of observations.
I believe the intel machine has hardware instructions which implement strcmp and that compilers support them. So even if strcmp is the bottleneck, I wouldn't expect it to show up on the profiler unless some sort of inlining were turned off. Or maybe the vtune profiler has special provision for these cases somewhere.
If you check for extended_type_info equality using strcmp very much, I cant see why it wouldnt be a bottleneck. I dont know the details of the serialization library, but my guess is that it must find the extended_type_info which matches the type given, depending on the complexity of your find algorithm, it may have unnecessary comparitions, that would point strcmp as the bottleneck.
I did check to verify that the strcmp in the type-id lookup has been removed. Instead we just make sure there is only one instance of a particular extended_type_info record so that we can just compare the addresses. There are still some optimizations to be implemented - but I can't predict how much they will speed up anything.
IMHO, profilers are essential before any work on optimization. Probably lots of optimizations wont even be needed, while others will make the real difference in speed. I have experienced that reusing containers(as someone already posted in this mailing list as a possible solution to some bottlenecks in the serialization library) to have huge impact in performance.
Robert Ramey
best regards, -- Felipe Magno de Almeida Developer from synergy and Computer Science student from State University of Campinas(UNICAMP). Unicamp: http://www.ic.unicamp.br Synergy: http://www.synergy.com.br "There is no dark side of the moon really. Matter of fact it's all dark."