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: didier <dgautheron@xxxxxxxx>
Date: Mon, 23 Mar 2009 18:29:11 +0100
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