Hi list,
Guy wrote:
>> The reason was basically performance. Value_string searches are O(n)
>
>Yes, I know, but does "match_strval()" take up a significant amount of
>time when reading/filtering/printing/etc. a capture file? What does a
>profiling run indicate?
A profiling run would probably show that match_strval() takes 0.0% of the time.
It was just an obvious optimization which would enhance performance by an unmeasurably
small amount. There was no analysis or profiling behind the change.
Please just put the VALS() thingy back into the patch. Is the patch acceptable with that change?
Are the other patches acceptable? I think of the NFS filehandle thingy and the initial
step for tvbuffification of smb.c ?
I tested smb_negprot on my laptop (though all my captures only show the case where wc==17, though both with and without the optional oem_domain unicode string)
I have a few other smb calls in my captures that I can start tvbuffificating.
best regards
ronnie sahlberg
