Hi,
Le lundi 23 mars 2009 ￜ 20:54 +0100, Joerg Mayer a ￜcrit :
> On Mon, Mar 23, 2009 at 06:29:11PM +0100, didier wrote:
> > 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.
>
> It most likely is.
As usual it's a trade-off.
- there's around 100 bug reports with a patch in bugzilla and the number
is rather growing than shrinking.
- There's 5 or 6 bugs about 'Wireshark is slow'.
As a rule of thumbs if I can't improve the speed par a factor two I
don't bother.
I would rather push for Yami SAT patch first because:
- It's not intrusive.
- It's easy to disable with a new preference.
- It really improves speed if you move back and forth between filters or
build the filter expression incrementally.
>
> > 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.
>
> That's not a problem any more: Changing the hinfo structure in the 1.1 tree
> is perfectly ok - we created the "stable" trees like 1.0 (and eventually 1.2)
> that guarantee a fixed API/ABI during the lifetime of these branches, but
> not between them.
existing bugs in dissectors are. An example in the new
epan/dissectors/packet-wassp.c dissector
static int
dissect_wassp(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree)
{
guint32 offset = 0;
...
if (tree) {
...
offset = x;
...
}
return offset;
}
if tree is NULL it returns 0, which is wrong.
it works with the SVN version most of the time because if coloring is
enable tree is never NULL (minus some taps).
In my version tree is not NULL only if you display the tree in the third
pane or you have a filter expression using some of the protocol fields.
A lot of dissectors have that kind of bugs and fail in weird way. I have
only fixed dissectors I'm using :)
Didier
