ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] one possible way to speed up filtering

From: yami <yamisoe@xxxxxxxxx>
Date: Tue, 24 Mar 2009 19:46:09 +0800
Hi

I've tried Didier's patch in Windows (compiled in MSVC 2005 Express with a few code tweak).

It is really fast. I hope one day it can come to trunk.

On Tue, Mar 24, 2009 at 1:29 AM, didier <dgautheron@xxxxxxxx> wrote:
Hi,
Le lundi 23 mars 2009 à 10:40 +0800, yami a écrit :

>
> I'm interested in:
>
> 1. how do you do profiling?
mainly with:
valgrind --tool=callgrind
and kcachegrind

I also did some runs with cache profiling tools.

> 2. which modifications contribute most?
Same as your stuff, try very hard to not decode packets.
For example with _expression_ using only protocols it's roughly a loop
like:
for i = 1 to nbe_packets
       if frame[i].trace & bitfield
               display_list[last++] = i

it doesn't even read the capture file.

> 3. Is there any plan to merge some improvements to trunk?
>
> For the last one, I find one of your posts in 2007 said you did have a
> plan, but due to bugzilla's issues, you did not submit them. What's
> the latest status of this plan now?
Some of them are already in wireshark.

There's still some small stuff which could go but It would only improve
wireshark speed by 20-40%, I'm not sure it's worth the time.

A big change is the per packet protocols bitfield but even if it's in
rather good shape it triggers a lot of existing bugs in dissectors,
breaks plugins (I changed hfinfo structure) and so on.

The last change is the packet list but it's a ugly hack and needs a lot
of work.

On the other hand I don't know if Wireshark speed is a problem for most
users, for a trace with a couple of ten thousand packets its current
speed is ok.

Maybe it's a prejudice, at first I thought that running Wireshark on
captures with millions packets was stupid, about using the right tool
and so on, but it's surprisingly useful.

Didier



___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe