I agree with performance concerns. BinarYLizable (why don't we rename it to Binarizable already, btw?) used to be the fastest approach to serialization (and it makes sense that manual approach is the best). With sorting it won't be so anymore.
On the other hand, incorrect ordering will break DML in a very unobvious way. We don't want loads of "I've inserted with DML and cache.get does not work" user list threads. To solve this, we can add add field order check to Binarylizable, something like if (fieldName.compareTo(prevFieldName) < 0) throw ... This should be fairly cheap and will make sure that binary representation is stable. Thoughts? On Mon, Apr 10, 2017 at 6:07 PM, Sergi Vladykin <sergi.vlady...@gmail.com> wrote: > Could you please elaborate why would we want to sort fields in > Binarilyzable > classes? > > If you are taking from stable binary representation perspective, then I > think it is a problem of user, but not ours. > > Sergi > > 2017-04-10 17:53 GMT+03:00 Vladimir Ozerov <voze...@gridgain.com>: > > > Zapalniki, > > > > Inspired by IGNITE-4669 (.NET: Sort binary object fields) [1]. > > > > Currently we sort binary object fields before when writing them to the > > output stream in case of standard (Serializable) objects and > > BinaryObjectBuilder. This makes sense as we have stable binary object > > representation irrespective of fields order, which is very important e.g. > > for DML. And it works fine from performance perspective as well: > > - For standard classes we sort fields only once during initialization; > > - For builder we have to maintain the whole object graph in memory before > > writing anyway as builder is mutable, so sorting doesn't impose serious > > performance hit. > > > > But what to do with Binarilyzable classes? We can sort their fields as > > well, but it means that: > > 1) We will not be able to write them directly to stream. Instead, we will > > accumulate values in memory, and write only when the whole object graph > is > > known. > > 2) Currently reads are mostly sequential from memory perspective. With > this > > change reads will become random. > > > > So we will loose both read and write serialization performance. How do > you > > think - do we need this change or not? > > > > Vladimir. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-4669 > > >
