C# library is allocation heavy on the Send() for message arrays, any chance for improvement?

Very interesting observations - and absent any direct changes to the SDK library, I am looking to see if there are any other workarounds apart from your manual garbage collection scheduling.

Can you clarify, the performance issues you observe are not necessarily on the allocations themselves, but on the garbage collection that results from it? Or are both impacting the observed performance?

I see. There are some internal discussions going on about this and, as you note, the optimizations are fairly straightforward apart from the fact a number of Solace users are still leveraging significantly older (perhaps even out-of-support) versions of .NET Framework. It would be possible to address this by changing what versions of .NET are supported or by using conditional compilation.

@Aleksei, that being said, while thinking about other workarounds and the general problem, you have got me curious about minimizing the impact of the GC, and I wanted to ask how are you handling the actual IMessage instances? Although you can manually control the unmanaged resources (alloc and free calls) via the provided .Dispose() implementation, are you avoiding GC on the managed instances somehow -- or are you re-using the messages and simply updating their payloads and headers?

Assuming there's no immediate fix to the package, are you interested in some (possibly hacky) workarounds to this issue? It may be possible to "rework" some of these methods using P/Invoke to grab some private IntPtr fields and DllImporting from the C API.

Even if not, if I can get a working example, I will share it (with the requisite caveats).

So, I will start this with a disclaimer: the following is merely sample code which shows a hypothetical "how it could be done", and bypasses much of the internal sanity checks, validations, etc. that the full .NET SDK (C Wrapper) provides. Also, because it involves reflection to obtain private fields, could break any time you upgrade the .NET SDK package.

With that out of the way, here is a very bare-bones helper class which allows a "mostly C#" application to directly invoke the C send multiple API. Note: as we discussed, it assumes that individual IMessage instances are going to be re-used. (I would be curious to hear how you are handling ITopic references as well.)

class MessageBatchSender: IDisposable
{
    IntPtr sessionPtr;
    IntPtr[] messagePtrs;
        
    public MessageBatchSender(ISession session)
    {
        this.Messages = Enumerable.Repeat<object>(null, 50).Select(_ => session.CreateMessage()).ToArray();
        this.messagePtrs = this.Messages.Select(GetPrivateIntPtr).ToArray();

        this.Session = session;
        this.sessionPtr = this.GetPrivateIntPtr(session);
    }

    public IMessage[] Messages { get; }
    public ISession Session { get; }

    public ReturnCode SendMessages(uint length, out uint messagesSent)
    {
        return SolClientSessionSendMultipleMsg(this.sessionPtr, this.messagePtrs, length, out messagesSent);
    }

    // This method could stop working if an SDK upgrade changes the internal implementation
    private IntPtr GetPrivateIntPtr(IMessage message)
    {
        var messageImplType = message.GetType();
        var messagePtrField = messageImplType.GetField("m_opaqueMessagePtr", BindingFlags.NonPublic | BindingFlags.Instance);
        return (IntPtr)messagePtrField.GetValue(message);
    }

    // This method could stop working if an SDK upgrade changes the internal implementation
    private IntPtr GetPrivateIntPtr(ISession session)
    {
        var sessionImplType = session.GetType();
        var sessionPtrField = sessionImplType.GetField("m_opaque", BindingFlags.NonPublic | BindingFlags.Instance);
        return (IntPtr)sessionPtrField.GetValue(session);
    }

    public void Dispose()
    {
        //TODO: Dispose all those IMessage instances!
    }

    [DllImport("libsolclient", CharSet = CharSet.Ansi, EntryPoint = "solClient_session_sendMultipleMsg", ExactSpelling = true)]
    [SuppressUnmanagedCodeSecurity]
    static extern ReturnCode SolClientSessionSendMultipleMsg(IntPtr opaqueSession, [MarshalAs(UnmanagedType.LPArray)] IntPtr[] opaqueMessages, uint msgArrayLength, out uint numMsgsSent);
}

And it can be used in this manner:

// Create context and session instances
using (var context = ContextFactory.Instance.CreateContext(contextProperties, null))
using (var session = context.CreateSession(sessionProperties, null, null))
{
    // Connect to the Solace messaging router
    Console.WriteLine($"Connecting as {username}@{vpnname} on {host}...");
    var connectResult = session.Connect();

    if (connectResult == ReturnCode.SOLCLIENT_OK)
    {
        Console.WriteLine("Session successfully connected.");

        // Create a topic and subscribe to it
        using (var publisher = new Helpers.MessageBatchSender(session))
        using (var topic = ContextFactory.Instance.CreateTopic("tutorial/topic"))
        {
            // This example assumes all messages have the same topic
            publisher.Messages[0].Destination = topic;
            publisher.Messages[0].BinaryAttachment = Encoding.UTF8.GetBytes("Msg 1");
            publisher.Messages[1].Destination = topic;
            publisher.Messages[1].BinaryAttachment = Encoding.UTF8.GetBytes("Msg 2");
            publisher.Messages[2].Destination = topic;
            publisher.Messages[2].BinaryAttachment = Encoding.UTF8.GetBytes("Msg 3");
            publisher.Messages[3].Destination = topic;
            publisher.Messages[3].BinaryAttachment = Encoding.UTF8.GetBytes("Msg 4");

            Console.WriteLine("Publishing messages...");
            var sendResult = publisher.SendMessages(4, out var messagesSent);
                                                     
            if (sendResult == ReturnCode.SOLCLIENT_OK)
            {
                Console.WriteLine($"Done. Sent {messagesSent} messages.");
            }
            else
            {
                Console.WriteLine($"Publishing failed, return code: {sendResult}");
            }
        }
    }
    else
    {
        Console.WriteLine($"Error connecting, return code: {connectResult}");
    }
}

There are no current plans to do so.

The use of the multi-messageSend(IMessage[], int, int) API is not particularly common or beneficial from a performance perspective except in very special circumstances; and the general recommendation is to use the single-message Send(IMessage) API unless there is a demonstrated benefit to the former.

It would be more likely, in my opinion, for the Solace SDK to merely fix the unnecessary allocations (per the OP) internally rather than leverage a hybrid C / C# API via IntPtr properties as shared in the sample code, above.

(Note: the code provided here is not intended for production use and is provided for demonstration purposes only.)

Regarding the use of Span / ReadOnlySpan / Memory / ReadOnlyMemory - improvements like these would be possible and are driven by customer asks.

One of the biggest challenges with maintaining an SDK with a very wide range of users is maintaining supportability for users who rely on legacy or even deprecated technologies. To date, Solace has maintained support for very old .NET technologies, and is still compatible with .NET Framework 2.0!

Theoretically, a next-gen Solace .NET API would be .NET Standard compliant, and include modern language features such as Span and async / await style APIs. But until then…

Very interesting approach, @rehan_azam786. Is the goal here to use a fixed or pre-allocated byte buffer which can be used multiple times as an IMessage.BinaryAttachment value? Without seeing the entire code base, I assume that you are only doing a single allocation with AllocHGlobal(…) and then reusing the unmanaged memory buffer for many messages. Is this correct?

Not sure how you can get the IntPtr opaqueMessage reference without reflection, though; but assuming you have that value calling the native method essentially what the .NET SDK is doing anyway — with the added perk of being able to specify the buffer size.

It would be nice if the SDK contained a IMessage.SetBinaryAttachment(byte[] buffer, int start, int length) method which would more or less accomplish the same and allow re-using the same (managed) memory array over and over for the entire application lifecycle assuming it was initialized with an appropriate initial size.