- This topic has 10 replies, 2 voices, and was last updated 8 years, 5 months ago by Anonymous.
December 31, 2013 at 15:04 #1365AnonymousInactive
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?
DavidDecember 31, 2013 at 15:09 #1366AnonymousInactive
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.
MarcJanuary 3, 2014 at 08:53 #1372AnonymousInactive
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.January 3, 2014 at 14:21 #1373AnonymousInactive
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?
MarcJanuary 6, 2014 at 09:31 #1375AnonymousInactive
I meant that the PacketHandlerCallBackDelegate’s incomingObject is null. I don’t experience a NullReferenceException.
DavidJanuary 6, 2014 at 11:08 #1376AnonymousInactive
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?
MarcJanuary 6, 2014 at 12:08 #1377AnonymousInactive
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.
DavidJanuary 6, 2014 at 14:47 #1378AnonymousInactive
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.
MarcJanuary 6, 2014 at 15:24 #1383AnonymousInactive
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.
MarcJanuary 7, 2014 at 15:51 #1391AnonymousInactive
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.
- You must be logged in to reply to this topic.