High memory allocation

[Anonymous]

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

[Anonymous]

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

[Anonymous]

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.

[Anonymous]

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

[Anonymous]

Hi Marc,

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

Regards,

David

[Anonymous]

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

[Anonymous]

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

[Anonymous]

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

[Anonymous]

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

[Anonymous]

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

[Author]

Posts