Ethereal-dev: Re: [Ethereal-dev] Performance. Ethereal is slow when using largecaptures.
----- 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.
