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