Wireshark-dev: Re: [Wireshark-dev] RFD: The Future of Memory Management in Wireshark
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Evan Huus <eapache@xxxxxxxxx>
Date: Tue, 23 Oct 2012 23:36:53 -0400
On Tue, Oct 23, 2012 at 11:10 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>
> On Oct 18, 2012, at 6:01 PM, Evan Huus <eapache@xxxxxxxxx> wrote:
>
>> I have linked a tarball [2] containing the following files:
>> - wmem_allocator.h - the definition of the allocator interface
>> - wmem_allocator_glib.* - a simple implementation of the allocator
>> interface backed by g_malloc and a singly-linked list.
>
> Presumably an implementation of the allocator could, instead of calling a lower-level memory allocator (malloc(), g_malloc(), etc.) for each allocation call, allocate larger chunks and parcel out memory from the larger chunks (as the current emem allocator does), if that ends up saving enough CPU, by making fewer allocate and free calls to the underlying memory allocator, so as to make it worth whatever wasted memory we have at the ends of chunks?

Absolutely: this is one of the things on my to-do list for wmem. I
haven't started it yet though. so if somebody else wants to grab it
that would be great.