[ENet-discuss] [near-PATCH] speed optimisation and bugfix: do one memory allocat ion per packet instead of two

Benoit Germain bgermain at ubisoft.fr
Fri Dec 10 00:14:44 PST 2004


Well, it all depends on how many packets are exchanged, but I did this for
the following reasons:

1) however insignificant the gain might be, it should not be spurned :-).
Any CPU cycles that are not spent in malloc can be used to generate
additional triangles for rendering, do better physics, whatever.
2) unless one replaces the standard memory allocator with one that traps
specific sizes to pool them, each packet you allocate eats effectively 32
bytes of memory (since your structure is 16 bytes long , there is an
overhead, and the usual allocators have a 16-bytes alignment policy), so if
you receive quite a number of packets without processing them, and memory is
sparse, it is a problem. In the last PS2 title I worked on, we had to run
the TCP stack with less that 300K of RAM.
3) usually when you deal with a packet header, chances are high you're going
to deal with the associated data. On systems with little data cache, cache
misses because the header is not contiguous to the data are another
performance hog. On the PS2, cache is very small, and misses are very
costly.

__________________________________
Benoit Germain
][ Engineer
+33 4 50 10 93 56
mailto:bgermain at ubisoft.fr
__________________________________
 

> -----Message d'origine-----
> De : enet-discuss-bounces at cubik.org 
> [mailto:enet-discuss-bounces at cubik.org] De la part de Lee Salzman
> Envoyé : vendredi 10 décembre 2004 02:53
> À : Discussion of the ENet library
> Objet : Re: [ENet-discuss] [near-PATCH] speed optimisation 
> and bugfix: do one memory allocat ion per packet instead of two
> 
> I have committed all the other bug fixes except this one. I 
> remain unconvinced that ENet's performance is significantly 
> dependent on malloc. If you can show actual profiles of ENet 
> running under significant network load where malloc is 
> dragging ENet down, I'd consider it.
> 
> Lee


More information about the ENet-discuss mailing list