Re: RFD: The Future of Memory Management in Wireshark

[Guy Harris <guy () alum mit edu>]

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?

___________________________________________________________________________
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