[Tomas Kukosa <tomas.kukosa@xxxxxxxxxxx>]

Guy Harris wrote:
> On Thu, Aug 05, 2004 at 11:33:21AM -0700, Guy Harris wrote:
>
> 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.

I though about it few months ago when the 1st performance improvements was done.

I have got following idea called "Reduced protocol tree":

 Requiremets are followng:
  - create flat tree (only root branch) with only required fields (for filtering, 
coloring, ...) if whole tree is not necessary
  - no changes in most of current dissectors

 Proposal how to do it:
  - mark required fields during initialization phase
     (I did not think about place where that information should be saved)
  - crate tree with "reduced" flag if whole tree is not necessary
  - bahaviour of proto_...() functions for "reduced tree" would be following:
      proto_tree_add_...():
         create item if necessary else return root item (or some dummy item)
      proto_tree_add_text(): return root item
      proto_item_append_...():  ignore
      proto_item_add_subtree(): return root branch


What do you think about it?