Memory

Memory

• Fragmentation: Sending and Receiving data with sockets produce memory fragmentations (more than usual) while fix memory segments to prevent the garbage collector relocate (because the operating system is using them). All this makes the GC can not do its job with the same efficiency as it usually does so a help from developers is welcome (but not required). Peer2Net implements its own memory manager to avoid fragmentation.

• Usage Limit: Many times we come across situations where we want to have some control over memory consumption, the reasons may be of different nature and is often complicated to implement. Peer2Net is able to limit the use of buffers such that if a socket requires memory to send or receive data but there isn't a large enough free buffer available, it postpones the execution until other sockets free as much memory as it needs, and if so executes the action.

• Instances Reuse: In an environment where potentially hundreds of sockets perform hundreds of operations per second, it is important to reduce the creation of new instances of objects that are used frequently. Although .NET is extremely efficient at this point, (it is able to create objects surprisingly fast), there are two special considerations where the implementation of pools of objects makes sense, the first reason is that the new asynchronous pattern sockets for high performance applications implicitly requires reuse of the SocketAsyncEventArgs instances. The second reason is to reuse instances that, while creating objects is really efficient, their creation requires more memory and extra work of destruction and relocation by the garbage collector. Peer2Net makes heavy usege of pooled objects.