[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