Ethereal-dev: Re: [Ethereal-dev] Ethereal performance, after Guy's changes ...
----- 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