Ethereal-dev: Re: [Ethereal-dev] Back to performance...
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?
