What about dissectors that register fields from other protocols? See the output of checkfiltername.pl run over the dissectors directory. Many of the display filters it (falsely) complains about are legitimate filter names because dissectors "share" fields.
-----Original Message-----
From: Evan Huus <eapache@xxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Mon, Jul 8, 2013 9:27 am
Subject: Re: [Wireshark-dev] RFC: Protocol fields list (reduce memory usage)
Great idea!
Are there any protocols whose hf fields are actually not consecutive?
I expect(/hope) even the ones that call proto_register_field_array
multiple times do so consecutively (ie 1-5,6-10,11-20 can be squished
into 1-20). If each protocol actually consists of only one consecutive
block we can get rid of the list entirely and just store the start/end
index directly in the protocol structure.
Even if we can't, an array might make more sense than a list. This
saves us the space of a pointer for protocols with only a single range
entry (most of them). It also allows us to coerce the index of the
range into the top byte of the iteration cookie, which (I think) will
brink the iteration speed back to what it was before.
Cheers,
Evan
On Sun, Jul 7, 2013 at 11:59 PM, Jakub Zawadzki
<darkjames-ws@xxxxxxxxxxxx> wrote:
> Hi,
>
> Right nowe for every protocol we have linked list with protocols fields. This
list in total takes about 1.5 MB
> (more than 100K hf fields, 16 bytes on 64bits per GList).
>
> This list is only used by two functions: proto_get_first_protocol_field() and
proto_get_next_protocol_field(), which are used only by gtk:
> - autocompletion
> - supported protocols list (Internals menu)
> - tree model for filter _expression_ dialog
>
> hf fields are commonly registered next to each other. We can reduce memory
usage
> if we replace SList iter per hf, with some range structure storing first hf
and last one.
>
> Attaching working PoC, listing all fields ordered by protocol takes some more
time
> (1.07s vs 0.04s compiled with -O0), but output is the same.
>
> I'd appreciate any comments / review / testing.
>
> Cheers,
> Jakub.
>
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe