Hi Raymond, First of all, BinaryObject is a cross-platform concept, it exists in C#, C++, Java. >From C# point of view there are some inconsistencies (like nullable Guid, or non-generic collections), but these things are dictated by the existing protocol, so we can't change them. In most cases you can just use WriteObject<>/ReadObject<> methods to avoid these inconsistencies.
1. You can implement array pooling yourself using IBinaryRawReader methods. For example, byte array is written like rawWriter.WriteByte(arr.Length); for (...) rawWriter.WriteByte(arr[i]); I think an extension method would be easy to write. 2. See above, use WriteObject<>/ReadObject<> to avoid dealing with nullables 3. Random array access is not possible with current API. Thanks, Pavel On Tue, Aug 1, 2017 at 2:46 AM, Raymond Wilson <[email protected]> wrote: > Hi, > > > > I’ve been looking at IBinarizable and IBinarySerializer with regards to > controlling object serialization (using the Ignite.Net client). > > > > A couple of questions: > > > > 1. Some of the APIs in IBinarizable allow for a factory methods to > control construction of collection and dictionary elements, but not for > array elements (which could allow for performance optimization through > array pooling). > > 2. GUID and DateTime elements are nullable (and there is no > non-nullable variant for these types). Apart from being inconsistent with > all the other types supported in the API, nullability in .Net carries a > performance penalty. Curious as to why these types are defined like this? > > 3. I see it is possible to read arrays of elements. But I see no > way to read a particular element within an array without deserialising the > entire array. Is it possible to do something like byte ReadByte(string > fieldname, uint index); ? > > > > Thanks, > > Raymond. > > >
