[ENet-discuss] Custom memory allocator

Lee Salzman lsalzman1 at cox.net
Tue Oct 30 03:40:24 PDT 2007


As far as I have ever benchmarked, the performance of GNU libc's malloc 
is pretty optimal, and internally, as far as I know, just has buckets 
for different memory sizes which wouldn't really be any worse than a 
customized memory pool. Packets are very short lived, so they're pretty 
much always going to be going back into the buckets as fast as they come 
out.

The bigger worry about a lot of packets is... bandwidth! Packets do 
require a small header, which starts to add up if you send a lot of 
little ones.

But a few hundred malloc/frees in a second is really nothing that won't 
easily be plowed through on a modern malloc implementation. So more or 
less, unless you it shows up in your profiles, I wouldn't bother messing 
with it.

Lee

Syed Setia Pernama wrote:
> Hi,
> 
> I have been wanting to ask this, but always keep forgetting until today ;)
> 
> Enet has provided a way for you to create a custom memory allocator, so that means instead of 'free' and 'malloc' everytime a packet is created & destroyed, we can instead pull it from a memory pool for an example.
> This way, memory fragmentation can be reduced significantly because depending on the app, there could be hundreds of free & malloc pair per second.
> 
> I know that this is critical in game console, but I am not sure too sure about PC - anybody can share some story here? Eg performance, stability - or it doesn't matter at all? :)
> 


More information about the ENet-discuss mailing list