["Lars Ruoff" <lars.ruoff@xxxxxxxxxxxxxxxxxx>]

----- Original Message ----- 
From: "Guy Harris" <guy@xxxxxxxxxxxx>
To: "Lars Ruoff" <lars.ruoff@xxxxxxxxxxxxxxxxxx>
Sent: Wednesday, November 19, 2003 11:03 AM
Subject: Re: [Ethereal-dev] Ethereal performance, after Guy's changes ...


> On Wed, Nov 19, 2003 at 11:01:08AM +0100, Lars Ruoff wrote:
> > Ok, i will try to get rid of constructing the protocol tree.
> > But does that improve performance
>
> Yes.  Constructing a protocol tree can be expensive.
>
> > It doesnt change the fact that the whole file does has to be
redissected,
> > does it?
>
> There are (at least) two ways of avoiding constructing the protocol tree
> when reading in the capture:
>
> 1) don't set up the tap unless the user asks for it - that means
>    that the file has to get redissected when the user asks for
>    that tap's window;

Yes, i know that. I wanted to avoid that by having the tap run when the
capture was redissected anyway (i.e. with *every* redissection) - that's why
i registered it on startup. As said, CPU overhead is nearly non-existant
(after my measurements) and memory-overhead was worth it when dealing with
RTP captures.
But i agree with you and Ronnie that this is a matter of personal opinion
and you shouldnt force *any* user to trade that memory against another
(slow) redissection.

>
> 2) set up the tap mechanism so that it lets you specify a tap
>    that doesn't require a protocol tree (which would be a tap
>    that has no filter) - that means that running the tap when
>    reading in the file doesn't require that the protocol tree be
>    constructed when you do that, and means that you don't have
>    to redissect the file when the user asks for that tap's
>    window (hopefully, what data structures it constructs don't
>    take up a lot of memory, and what processing it does when the
>    file is read in is cheap).

If what you say means that this kind of redissection (without constructing
p-tree) is *fast* (how fast?) then of course my arguments for the first
point vanish and we should *definitely* have the tap running only when the
window is requested.

If it is still somewhat slow, then i suggest a user preferences option.

Lars Ruoff