Ethereal-dev: Re: [Ethereal-dev] Performance. Ethereal is slow when usinglargecaptures.
----- Original Message -----
From: "Ronnie Sahlberg"
Sent: Sunday, November 16, 2003 11:27 AM
Subject: Re: [Ethereal-dev] Performance. Ethereal is slow when
usinglargecaptures.
>
> ----- Original Message -----
> From: "Guy Harris"
> Sent: Sunday, November 16, 2003 11:04 AM
> Subject: Re: [Ethereal-dev] Performance. Ethereal is slow when using
> largecaptures.
>
>
> > On Sat, Nov 15, 2003 at 02:29:21PM +1100, Ronnie Sahlberg wrote:
> > > 1, We need to remember all COL values for all packets so that we can
> just
> > > reapply them when adding the packet to the packetlist without calling
> the
> > > dissector and recreating them that way. This will consume additional
> > > memory.
> >
> > Note that sometimes col values change on a redissection, e.g. if a
> > protocol preference is changed or if the display format for the time
> > changes.
>
> Yes. We need two different rescan_packets() functions. One that performs
a
> full rescan as it does today
> which includes a full redissection of every packet.
> Common things that would require this since the packets might be dissected
> differently and thus the list
> of filter items in the packet and COL entries might change are
> when we change preference options (most of them)
> when we use DecodeAs.
> IMO these instances do not happen that frequently so it would be ok to
just
> allow a full redissection of the packets.
>
> Another common case which might cause a packet to be dissected differently
> is when we have state spilling over from
> one packet to another, like when we have found a Response packet, this
will
> cause the Call packet, next time it is dissected,
> to have an additional filter item in the tree "Response In:xxx".
> Many/Most of these instances when this happens are associateds with a
> FT_FRAMENUM field being added to the tree.
> Making FT_FRAMENUM cause an unconditional redissection of the packet it
> points to would solve IMO 99% of those cases.
> (we would however need the ability to sometimes dissect/redissect packets
> out-of-order for this to work)
>
> I think these issues can be solved without too many problems.
>
> >
> > Note also that it will probably consume a significant amount of memory -
> > in fact, it already *does* consume a significant amount of memory,
> > because the GtkClist for the summary pane keeps strings for all the
> > values.
> >
>
> Maybe it is possible to tell GTK that, hey I have provided a persistend
> g_string here, DO NOT make your own internal copy of this string, use
> the pointer I provided.
> I promise to keep the string around as long as the GTK object lives or
else
> I am prepared to face the consequences.
>
> This would make it not really consume that much memory at all (since we
> trade storing them inside some GTK object for storing the strings
somewhere
> in our own structures instead.
Or if we always keep all packets in the packetlist CList instead of just
those that have passed some sort of filter expression,
then we could show/hide packets using show-widget/hide-widget and we
wouldnt need to
keep a copy of the COL strings around
redissect the packet
just do a show-widget if the new filter applied a packet should be shown
again or hide-widget if it shouldnt.
It would still allow us to update the packet list accordingly whenever we
have applied a new filter without needing to
redissect the packets.
This might be a much easier thing to implement anyway (complete guess)
>
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
