When a large message with many repeating groups is received, for example, SecurityList (y), the session allocates the memory for this message and each repeating group instance. This can increase memory consumption, especially when there are many such sessions. For performance reasons, this memory is not deallocated during the FIX connection lifetime because the deallocation and further allocation of new memory are expensive, so it cannot be performed after receiving each message. This memory is deallocated only after the Session.Logout() call. However, in some cases, it makes sense to have the ability to shrink this memory after receiving large messages. In such cases, ScheduleShrinkToFit() method can be used. This method will schedule the memory usage optimization of the receiving part. The session will perform the actual memory usage optimization after receiving and processing the next session-level incoming message.

When a session sends messages at a high rate or the counterparty cannot process them fast enough, the system socket is overflowed and cannot accept new data, and the Send(Message) method stores outgoing messages in the sending queue for the following process in the sending thread. Transferring an outgoing message to the sending queue is done via the message pool. The message pool memory is not deallocated after each message processing for performance reasons. The pool returns memory in time following a heuristic algorithm when the message rate decreases. However, in different scenarios, when there is a long period between high-rate sending, the memory can leave occupied until the next sending activity period. Therefore, it makes sense to have the ability to shrink the pool memory after an overflow issue. In such cases, the same ScheduleShrinkToFit() method can be used. This method will schedule the memory usage optimization of the sending part. The session will perform the actual memory usage optimization before sending the next outgoing session-level message.

Note
The ScheduleShrinkToFit() method should be used when an overflow issue is gone. One can detect it by the OutboundQueueBytes method. Please see the Controlling Outgoing Message Flow topic for details.