ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

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

From: Jeff Morriss <jeff.morriss.ws@xxxxxxxxx>
Date: Fri, 07 Jan 2011 17:52:57 -0500
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.

Soon after that I realised that to spend 30% of CPU reading text lines from the file (in wiretap) was too high. When I configured to compile without zlib support that went down to 0.3%, and I haven't worried too much about performance since then.

I remember you mentioning that before... Another reason to kick zlib out so we can be sure to have fast random access to files. :-)