[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