Wireshark · Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 35393: /trunk/epan/dissectors/ /trunk/epan/dissectors/:

[Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>]

On 01/07/2011 05:52 PM, Jeff Morriss wrote:
> Martin Mathieson wrote:
> > After remembering that profiling (at least in its easiest form with
> > the 'time' command) isn't so hard, I played around a bit. After
> > building a decent-sized dct2000 file (taking the sample from
> > SampleCaptures and merging it with itself until I had a 276 Mb
> > file), I tried before and after this change and I can't find a
> > measurable difference in the CPU usage. I even tried forcing my
> > (AMD) CPU down to 1 GHz to exaggerate the difference, but I still
> > got only a couple of seconds CPU time difference out of over 5
> > minutes--and in that case rev 35393's code was faster.
> >
> > Maybe I'll try tomorrow on a SPARC: I know that memcpy()s are a lot
> > more expensive there than on x86.
> >
> >
> > I think you win, the difference isn't worth it and it'd be better not
> > to leave unnecessary examples of tvb_get_ptr() use around.
>
> I tried with SPARC today and I do see a consistent 0.9% difference in
> CPU time before and after 35393. (In particular I see about 6-7 seconds
> of extra CPU time in a tshark job that takes around 11 minutes and 50
> seconds.)
>
> Don't know if that difference is significant enough to matter.

(After entirely too much time trying to find a way to rebuild my NAS' 
disk array--shaking in my boots the whole time--I finally got back to this.)

I eventually decided to go ahead and check in tvb_get_const_stringz(): 
when using tshark I could eventually (once I got the capture file up to 
about 1 Gb) detect a measurable amount of CPU time saved, even on x86. 
(Before I had been using the GUI but the CPU usage seemed to vary too 
much.)  Since there doesn't seem to be any harm in it and it's more 
efficient, I figured why not...