Re: RFD: The Future of Memory Management in Wireshark

[Evan Huus <eapache () gmail com>]

On Tue, Oct 23, 2012 at 11:10 PM, Guy Harris <guy () alum mit edu> wrote:
> On Oct 18, 2012, at 6:01 PM, Evan Huus <eapache () gmail com> 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.
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe