[Guy Harris <gharris@xxxxxxxxx>]

On Thu, Aug 05, 2004 at 11:33:21AM -0700, Guy Harris wrote:
> Given my experience when we had a memory leak, in the early days of the
> protocol tree code, that caused protocol trees not to be freed, if we do
> that, we'd definitely want to make it optional - when it had that leak,
> Ethereal thrashed pretty badly when loading a large capture file.

Hmm.

Part of the issue here is that a full-blown protocol tree is probably a
waste - most of the fields aren't going to be looked at.

So perhaps something to attach to the packet only the fields that were
being used in the filter would do the job here.

However, that means that they'd be cached only on the second and
subsequent filters - so perhaps having Ethereal remember, in a file,
what fields the user has filtered on, and set those fields up when
reading the capture, would be the right thing to do.

That'd require us to change dissectors not to skip any part of
dissection if the protocol tree isn't being built; I don't know how much
of a performance impact that'd have.  If it's significant, the caching
of "interesting" fields could be made a preference.