ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pavel Tupitsyn <ptupit...@apache.org>
Subject Re: Sorting fields of Binarilyzable objects on write
Date Mon, 10 Apr 2017 15:11:36 GMT
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.vladykin@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 <vozerov@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message