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...
