My favorites | Sign in
Project Home Downloads Wiki Issues Source
Search
for
Optimization  
Optimizing for performance and bandwidth
Featured
Updated Jun 26, 2011 by lidg...@gmail.com

How to optimize Lidgren

  • Recycle incoming messages. This will put less strain on the garbage collector and thus faster GC sweeps.
  • Preallocate size in NetOutgoingMessage by using the CreateMessage(int) method. This will remove the need for the library to resize the buffer as you add data to it - relieving GC pressure.
  • Disable unused message types. This will reduce the amount of unused messages created which reduces both GC pressure and cpu time to create them.
  • Tweak the NetPeerConfiguration values. They can help with latency, bandwidth usage and memory usage.
  • To save on bandwidth; use the smallest data type necessary and consider using Write(value, numbits), WriteVariableInt32(), WriteRangedInteger(), WriteUnitSingle() etc to encode your data.
  • Use unreliable channels for data that does not absolutely need to be reliable. This will reduce the amount of memory used to store not-yet-acknowledged messages. It will also reduce the amount of cpu used to track reliable messages.
Comment by robin.th...@gmail.com, Mar 13, 2011

The initialCapacity of CreateMessage(int) is measured in bytes. Strings written to the NetOutgoingMessage is converted to bytes using UTF-8 which can 1-4 bytes per character hence making string.Length useless. Use Encoding.UTF8.GetByteCount(string) to get an accurate byte count. Remember to add 1 byte extra per string for string termination.

Comment by project member lidg...@gmail.com, Mar 26, 2011

Correct; except that strings aren't null terminated when they're sent over the network (since .net strings can contain null characters) - the length is prepended using WriteVariableUInt32; so the final number of bytes are a bit harder to determine. For performance sake it's easier to overallocate a byte or two to be on the safe side.


Sign in to add a comment
Powered by Google Project Hosting