ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergi Vladykin <sergi.vlady...@gmail.com>
Subject Re: Sorting fields of Binarilyzable objects on write
Date Mon, 10 Apr 2017 15:33:19 GMT
I even think that in DML we have to just calculate hashCode in order of
QueryEntity regardless of order in Binarylizable.

Sergi

2017-04-10 18:29 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:

> Does anyone disagree about having users sort the fields themselves, as
> Sergi and I suggested above?
>
> On Mon, Apr 10, 2017 at 8:21 AM, Pavel Tupitsyn <ptupitsyn@apache.org>
> wrote:
>
> > Sergi, DML writes fields in alphabetic order and computes hash code
> > accordingly.
> > If user-defined Binarylizable impl uses different order, hash codes will
> be
> > inconsistent.
> >
> > On Mon, Apr 10, 2017 at 6:18 PM, Sergi Vladykin <
> sergi.vladykin@gmail.com>
> > wrote:
> >
> > > What is correct or incorrect ordering for DML?
> > >
> > > Sergi
> > >
> > > 2017-04-10 18:14 GMT+03:00 Dmitriy Setrakyan <dsetrakyan@apache.org>:
> > >
> > > > I would agree that it should be on a user to always sort the fields,
> if
> > > we
> > > > make it a part of the contract. However, in this case, we should
> always
> > > > throw exception if user somehow provides fields in the wrong order.
> > > >
> > > > D.
> > > >
> > > > On Mon, Apr 10, 2017 at 8:07 AM, 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