Performance improvement #236

asimarslan · 2019-05-02T14:18:28Z

performance improvement on serialization bits, codecs and lazyDictioary introduced

devOpsHazelcast · 2019-05-02T14:23:36Z

Windows .Net Framework Tests FAILed.

devOpsHazelcast · 2019-05-02T14:40:04Z

Linux Net Core Tests FAILed.

devOpsHazelcast · 2019-05-02T14:42:03Z

Windows Net Core Tests FAILed.

asimarslan · 2019-05-03T08:32:34Z

verify

devOpsHazelcast · 2019-05-03T08:37:08Z

Windows .Net Framework Tests FAILed.

devOpsHazelcast · 2019-05-03T08:55:38Z

Linux Net Core Tests FAILed.

devOpsHazelcast · 2019-05-03T08:56:16Z

Windows Net Core Tests FAILed.

sancar · 2019-05-03T08:58:08Z

Hazelcast.Net/Hazelcast.Client.Proxy/ClientMapNearCacheProxy.cs

+                    object value;
+                    if (_nearCache.TryGetValue(keyData, out value))
+                    {
+                        keyList.Remove(keyData);


We are iterating over the keyList with indexes and calling remove in the middle. It looks like we will have array index out of bound exception.

reverted the iteration

devOpsHazelcast · 2019-05-03T09:13:47Z

Linux Net Core Tests FAILed.

devOpsHazelcast · 2019-05-03T09:20:51Z

Windows .Net Framework Tests FAILed.

devOpsHazelcast · 2019-05-03T09:39:09Z

Windows Net Core Tests FAILed.

ihsandemir · 2019-05-03T08:14:48Z

Hazelcast.Net/Hazelcast.Client.Protocol.Codec/MapEntriesWithPredicateCodec.cs

        }

-        internal class ResponseParameters
+        internal static void DecodeResponse(IClientMessage clientMessage, ConcurrentQueue<KeyValuePair<IData, object>> result)


Is the optimization using a concrete implementation instead of the interface? Can you share the performance numbers how this improves performance?

What about elimination of the class ResponseParameters class with the static method?
I see that only 5 codecs are changed, should this be applied to all the other codecs as well?

This is a IMap optimization that we can backport in 4.0 series to all codecs

ihsandemir · 2019-05-03T08:18:42Z

Hazelcast.Net/Hazelcast.Client.Protocol.Codec/MapGetAllCodec.cs

            dataSize += ParameterUtil.CalculateDataSize(name);
            dataSize += Bits.IntSizeInBytes;
-            foreach (var keysItem in keys)
+            for (int i = 0; i < keys.Count; i++)


does this change affect performance?

on .Net foreach is slower than for loop

ihsandemir · 2019-05-03T08:23:34Z

Hazelcast.Net/Hazelcast.Client.Protocol.Util/BufferBuilder.cs

                var newCapacity = QuickMath.NextPowerOfTwo(requiredCapacity);
                var newBuffer = new byte[newCapacity];
-                Array.Copy(_protocolBuffer.ByteArray(), 0, newBuffer, 0, _capacity);
+                Buffer.BlockCopy(_protocolBuffer.ByteArray(), 0, newBuffer, 0, _capacity);


Is this the performance improvement? :
Array.Copy iterates each element while Buffer.BlockCopy performs block of memcpy? So, can we assume that we always need to prefer memcpy to iteration?

Buffer.BlockCopy is faster than Array.Copy. both are native calls and I'm not sure of the reason. I can measure improvement.

ihsandemir · 2019-05-03T08:25:17Z

Hazelcast.Net/Hazelcast.Client.Protocol.Util/SafeBuffer.cs

        }

-        public virtual void PutLong(int index, long value)
+        public  void PutLong(int index, long value)


This is interesting. So, virtual methods and interfaces seem to decrease performance for .Net. I am surprised that the .NET virtual machine does not optimize these usages.

yes virtual methods and interface calls add extra overhead.

ihsandemir · 2019-05-03T08:29:52Z

Hazelcast.Net/Hazelcast.Client.Protocol.Util/SafeBuffer.cs

-        public virtual void GetBytes(int index, byte[] dst, int offset, int length)
+        public  void GetBytes(int index, byte[] dst, int offset, int length)
        {
-            BoundsCheck(index, length);


This seems to be also unneeded even if previously when Array.Copy was used, since Array.Copy method also does bounds check and throw ArgumentOutOfRangeException when length was not sufficient, right? I wonder how much performance affect this had.

I removed it as it's unnecessary. This is bound check is on all of the hot path so every peny count on this kink of hot paths.

ihsandemir · 2019-05-03T08:35:23Z

Hazelcast.Net/Hazelcast.Client.Proxy/ClientMapNearCacheProxy.cs

-            for (var i = 0; i < resultingKeyValuePairs.Count;)
+            });
+            base.GetAllInternal(partitionToKeyData, resultingKeyValuePairs);
+            Parallel.ForEach(resultingKeyValuePairs, kvp =>


interesting optimization. does this speed up when number of entries is over a certain number or is it better to use even if the number of keys is small like say 5 (since I assume there will be a cost of splitting the data to different threads and merging) ?

ihsandemir · 2019-05-03T08:39:25Z

Hazelcast.Net/Hazelcast.Client.Proxy/ClientMapProxy.cs

+                ExceptionUtil.Rethrow(e);
            }
-            return result;
+            return new ReadOnlyLazyDictionary<TKey, TValue>(resultingKeyValuePairs, GetContext().GetSerializationService());


Do you have a performance number for how much this lazy usage improve the performance in case where the object is always used and deserialized finally event when lazy?

ihsandemir · 2019-05-03T08:41:40Z

Hazelcast.Net/Hazelcast.Client.Proxy/ClientMapProxy.cs

+            var partitions = new ArrayList(partitionCount);
+            for (var i = 0; i < partitionCount; i++)
+            {
+                partitions.Add(ArrayList.Synchronized(new ArrayList()));


do we really need a Synchronized list here?

yes the next parallel loop will use it but when I benchmark it, I saw itS even faster than concurrentQueue as most of the time is used on the serialization and threads rarely make sync calls.

ihsandemir · 2019-05-03T08:48:42Z

Hazelcast.Net/Hazelcast.Util/ReadOnlyLazyList.cs

+                }
+                else
+                {
+                    if (itemData.Equals(serializationService.ToData(dValue)))


would you benefit if you cache this deserialized object? A second call to Contains will be much faster using the cache, right?

A second call to Contains is quite a rare case for this list. 99% will just loop over it. But if I cache it, that will be a memory overhead for every case.
Moreover contains method is just implemented just not to leave it empty.

devOpsHazelcast · 2019-05-03T12:13:06Z

Linux Net Core Tests FAILed.

devOpsHazelcast · 2019-05-03T12:18:05Z

Windows .Net Framework Tests FAILed.

devOpsHazelcast · 2019-05-03T12:35:07Z

Windows Net Core Tests FAILed.

devOpsHazelcast · 2019-05-03T13:00:46Z

Linux Net Core Tests FAILed.

devOpsHazelcast · 2019-05-03T13:08:36Z

Windows .Net Framework Tests FAILed.

devOpsHazelcast · 2019-05-03T13:26:06Z

Windows Net Core Tests FAILed.

devOpsHazelcast · 2019-05-03T14:30:29Z

Linux Net Core Tests FAILed.

devOpsHazelcast · 2019-05-03T14:39:02Z

Windows .Net Framework Tests FAILed.

devOpsHazelcast · 2019-05-03T14:55:34Z

Windows Net Core Tests FAILed.

devOpsHazelcast · 2019-05-03T15:15:31Z

Linux Net Core Tests FAILed.

devOpsHazelcast · 2019-05-03T15:22:53Z

Windows .Net Framework Tests FAILed.

devOpsHazelcast · 2019-05-03T15:40:02Z

Windows Net Core Tests FAILed.

devOpsHazelcast · 2019-05-03T17:31:05Z

Windows .Net Framework Tests FAILed.

devOpsHazelcast · 2019-05-03T17:31:12Z

Windows Net Core Tests FAILed.

devOpsHazelcast · 2019-05-03T17:34:59Z

Linux Net Core Tests FAILed.

devOpsHazelcast · 2019-05-03T17:47:00Z

Linux Net Core Tests FAILed.

devOpsHazelcast · 2019-05-03T17:48:17Z

Windows Net Core Tests FAILed.

devOpsHazelcast · 2019-05-03T17:59:02Z

Windows .Net Framework Tests FAILed.

asimarslan · 2019-05-03T18:00:26Z

verify

devOpsHazelcast · 2019-05-03T18:16:55Z

Linux Net Core Tests FAILed.

devOpsHazelcast · 2019-05-03T18:17:43Z

Windows Net Core Tests PASSed.

devOpsHazelcast · 2019-05-03T18:32:04Z

Windows .Net Framework Tests FAILed.

asimarslan · 2019-05-03T18:43:45Z

run-net

devOpsHazelcast · 2019-05-03T19:11:12Z

Windows .Net Framework Tests FAILed.

…ary introduced

devOpsHazelcast · 2019-05-03T19:35:46Z

Linux Net Core Tests PASSed.

devOpsHazelcast · 2019-05-03T19:43:16Z

Windows .Net Framework Tests PASSed.

devOpsHazelcast · 2019-05-03T19:59:51Z

Windows Net Core Tests PASSed.

asimarslan added this to the 3.12 milestone May 3, 2019

asimarslan force-pushed the feature/performance-improvements branch from 036c96f to f91f491 Compare May 3, 2019 08:53

asimarslan requested review from ihsandemir and sancar May 3, 2019 08:57

asimarslan changed the title ~~[WIP]performance improvement~~ Performance improvement May 3, 2019

sancar reviewed May 3, 2019

View reviewed changes

ihsandemir reviewed May 3, 2019

View reviewed changes

asimarslan force-pushed the feature/performance-improvements branch from f91f491 to a8b605c Compare May 3, 2019 11:52

asimarslan force-pushed the feature/performance-improvements branch from a8b605c to 2f45345 Compare May 3, 2019 12:41

sancar approved these changes May 3, 2019

View reviewed changes

asimarslan force-pushed the feature/performance-improvements branch from 2f45345 to 1cdb044 Compare May 3, 2019 14:11

ihsandemir approved these changes May 3, 2019

View reviewed changes

asimarslan force-pushed the feature/performance-improvements branch from 1cdb044 to 0d4ae8c Compare May 3, 2019 14:58

asimarslan force-pushed the feature/performance-improvements branch 2 times, most recently from 0f08169 to b719af2 Compare May 3, 2019 17:30

performance improvement on serialization bits, codecs and lazyDiction…

052dc34

…ary introduced

asimarslan force-pushed the feature/performance-improvements branch from b719af2 to 052dc34 Compare May 3, 2019 19:19

asimarslan merged commit 4c28d90 into hazelcast:master May 3, 2019

Performance improvement #236

Performance improvement #236

Uh oh!

Conversation

asimarslan commented May 2, 2019

Uh oh!

devOpsHazelcast commented May 2, 2019

Uh oh!

devOpsHazelcast commented May 2, 2019

Uh oh!

devOpsHazelcast commented May 2, 2019

Uh oh!

asimarslan commented May 3, 2019

Uh oh!

devOpsHazelcast commented May 3, 2019

Uh oh!

devOpsHazelcast commented May 3, 2019

Uh oh!

devOpsHazelcast commented May 3, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

devOpsHazelcast commented May 3, 2019

Uh oh!

devOpsHazelcast commented May 3, 2019

Uh oh!

devOpsHazelcast commented May 3, 2019

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

asimarslan May 3, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

devOpsHazelcast commented May 3, 2019

Uh oh!

devOpsHazelcast commented May 3, 2019

Uh oh!

devOpsHazelcast commented May 3, 2019

Uh oh!

devOpsHazelcast commented May 3, 2019

Uh oh!

devOpsHazelcast commented May 3, 2019

Uh oh!

devOpsHazelcast commented May 3, 2019

Uh oh!

devOpsHazelcast commented May 3, 2019

Uh oh!

devOpsHazelcast commented May 3, 2019

Uh oh!

asimarslan May 3, 2019 •

edited

Loading