[ENet-discuss] Custom memory allocator

[Beau Albiston]

Perhaps another use for the memory interface would be to allow external 
tracking of memory, specifically in the case where you have written 
wrappers around alloc/free for debugging purposes?

-Beau

Lee Salzman wrote:
> 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? :)
>>
>>     
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>
> __________ NOD32 2627 (20071030) Information __________
>
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
>
>
>
>