Home Forums Support High memory allocation

  • This topic has 10 replies, 2 voices, and was last updated 8 years ago by Anonymous.
Viewing 10 posts - 1 through 10 (of 11 total)
  • Author
    Posts
  • #1365
    Anonymous
    Inactive

    Hi,

    I’m currently testing your product, it’s very easy to use. But I’m experiencing very high memory allocation that I first noticed in the task manager looking at peeks of 700MB usage.

    It’s basically serialization LZ.BinTree.Create and LZMA.LZ.OutWindow.Create methods that allocate a lot of memory according to my profiling sessions. In my test span it allocates more than 10GB compared to no significant allocation when I switch to WCF over TCP. I’m not doing heavy work but a simple duplex communication channel. How can I disable the compression to test passing only byte arrays?

    There is also a larger memory footprint than WCF. Is there tweaks?

    Regards,

    David

    #1366
    Anonymous
    Inactive

    Welcome to our forums and many thanks for your interest in our network library.

    As you have found most memory allocations come from the compression/decompression stages. Disabling compression is straight forward to do globally, just change NetworkComms.DefaultSendReceiveOptions:

    NetworkComms.DefaultSendReceiveOptions = new SendReceiveOptions<ProtobufSerializer>();

    If you only intend to used pure byte[] then you can go a step further an also disable the serialisation stages (there is a very small additional overhead to sending byte[] if the serialisation stage is enabled):

    NetworkComms.DefaultSendReceiveOptions = new SendReceiveOptions<NullSerializer>();

    For more info please see our tutorial on SendReceiveOptions here.

    Regards,
    Marc

    #1372
    Anonymous
    Inactive

    Thanks for your response.

    When I use the SendReceiveOptions as you mentioned I receive null references. I really to test this asap as it would be a burden to have such high memory pressure for such simple objects.

    #1373
    Anonymous
    Inactive

    Heya David,

    I will help however I can. What version are you using and can you give me a full stack trace of the null reference exception?

    Regards,
    Marc

    #1375
    Anonymous
    Inactive

    Hi Marc,

    I meant that the PacketHandlerCallBackDelegate’s incomingObject is null. I don’t experience a NullReferenceException.

    Regards,

    David

    #1376
    Anonymous
    Inactive

    Morning David,

    The following would help:

    1. What are you sending when you receive a null as the incoming Object?
    2. Is it reproducible?
    3. Could confirm the exact send receive options you are using.
    4. What version of networkcomms.net are you using?

    Kind regards,
    Marc

    #1377
    Anonymous
    Inactive

    Hi Marc,

    You’re right I should have provided all that. Let me try to reproduce in a test project. I’m sending ProtoContracts and primitives. I’m using the latest version.

    Regards,

    David

    #1378
    Anonymous
    Inactive

    Speaking with other developers you may be seeing a bug in v2.3.0. We fixed this in v2.3.1. I’m just putting together the download now, so it should be available within the next couple of hours.

    Marc

    #1383
    Anonymous
    Inactive

    Version 2.3.1 is now available in the download section. If you are able to reproduce the problem using 2.3.0 and moving to 2.3.1 fixes the problem please let us know.

    Regards,
    Marc

    #1391
    Anonymous
    Inactive

    Hi Marc,

    The bug is fixed.

    Using no compression stopped the high memory pressure and is now inexistant. Also, the memory footprint of simply loading the library is much lighter. The difference is very surprising.

    Regards,

    David

Viewing 10 posts - 1 through 10 (of 11 total)
  • You must be logged in to reply to this topic.