Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Interesting thing about "recent" changes in GHashTable

From: Evan Huus <eapache@xxxxxxxxx>
Date: Tue, 13 Aug 2013 18:15:28 -0400
Not worth it in my opinion unless the memory savings are significant (I suspect they are only in the range of a few-hundred KB).


On Tue, Aug 13, 2013 at 1:35 PM, Jakub Zawadzki <darkjames-ws@xxxxxxxxxxxx> wrote:
On Tue, Aug 13, 2013 at 01:12:18PM -0400, Evan Huus wrote:
> Anyone building with a new enough glib will get this behaviour for free? So
> I don't think it's worth backporting to older builds unless the memory
> savings are really significant...

I don't want to backport it, I was thinking about using it.

for example 'registered_dissectors' from packet.c:

Right now we have:

2018         g_hash_table_insert(registered_dissectors, (gpointer)name,
2019                             (gpointer) handle);

but name is also accessible by handle

2013         handle->name          = name;

so we could do:
  g_hash_table_insert(registered_dissectors, handle, handle);

but it'd requires some changes:
  - for hash function, g_str_hash() can't be called directly, but new function with just g_str_hash(handle->name)
  - for lookup code (find_dissector())
    instead of simple:
       g_hash_table_lookup(registered_dissectors, name);

    we'd need to do:
      dissector_handle_t temp;

      temp.name = name;
      g_hash_table_lookup(registered_dissectors, &temp);

the second part is this 'hacky' thing.
___________________________________________________________________________
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