[RFC] Do not clone-demerge-compare, just compare taking capabilities into account

[Henrik /KaarPoSoft-2]

Dear all,

Following up on a previous thread on this list:

>> The current logic in _osync_obj_engine_mapping_find is:
>> Clone (i.e. make a complete copy of) change1. Demerge fields from the
>> clone which are not in caps2.
>> Clone (i.e. make a complete copy of) change2. Demerge fields from the
>> clone which are not in caps1.
>> Compare the two cloned objects.
>> To me this seems unnecessarily complicated and incurs a performance
>>  penalty. Why is this not implemented as a more "intelligent" compare
>>  function, which takes capabilities into account?

> This is pretty new code and more or less just a proof of concept. If you came
> up with a more efficient solution, let me know. This was the last thing i was
> working on ... it's not completed.


OK, here is a suggestion:

In  _osync_obj_engine_mapping_find in opensync_obj_engine.c we currently have something which boils down to:

clone_change1 = _osync_obj_engine_clone_and_demerge_change(sinkengine->engine, caps2, change1, error);
clone_change2 = _osync_obj_engine_clone_and_demerge_change(sinkengine->engine, caps1, change2, error);
change1 = clone_change1;
change2 = clone_change2;
tmp_result = osync_change_compare(change1, change2, error);

This could be replaced with

tmp_result = osync_change_compare(change1, change2, caps1, caps2, error);

osync_change_compare and thus osync_data_compare and osync_objformat_compare and maybe other functions would require trivial changes.

It would then boil down to modifying functions like osync_objformat_compare to take capabilities into account (not trivial).

As far as I can see, this would be a far more efficient solution.

The drawback is of course that it needs coding work (=time).

However, as demerge_xmlformat needs heavy work anyway, I think this may be a good time to consider replacing clone-demerge-compare with a compare taking capabilities into account.

What do you all think about this proposal?

/Henrik

PS: This was about demerge. I have not quite figured merge out, maybe somebody more knowledgeable than me could comment on this...




------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel

[Daniel Gollub-3]

On Saturday 24 October 2009 04:13:33 pm Henrik /KaarPoSoft wrote:

> Dear all,
>
> Following up on a previous thread on this list:
> >> The current logic in _osync_obj_engine_mapping_find is:
> >> Clone (i.e. make a complete copy of) change1. Demerge fields from the
> >> clone which are not in caps2.
> >> Clone (i.e. make a complete copy of) change2. Demerge fields from the
> >> clone which are not in caps1.
> >> Compare the two cloned objects.
> >> To me this seems unnecessarily complicated and incurs a performance
> >>  penalty. Why is this not implemented as a more "intelligent" compare
> >>  function, which takes capabilities into account?
> >
> > This is pretty new code and more or less just a proof of concept. If you
> > came up with a more efficient solution, let me know. This was the last
> > thing i was working on ... it's not completed.
>
> OK, here is a suggestion:
>
> In  _osync_obj_engine_mapping_find in opensync_obj_engine.c we currently
>  have something which boils down to:
>
> clone_change1 =
>  _osync_obj_engine_clone_and_demerge_change(sinkengine->engine, caps2,
>  change1, error); clone_change2 =
>  _osync_obj_engine_clone_and_demerge_change(sinkengine->engine, caps1,
>  change2, error); change1 = clone_change1;
> change2 = clone_change2;
> tmp_result = osync_change_compare(change1, change2, error);
>
> This could be replaced with
>
> tmp_result = osync_change_compare(change1, change2, caps1, caps2, error);
>
> osync_change_compare and thus osync_data_compare and
>  osync_objformat_compare and maybe other functions would require trivial
>  changes.

Actually i hesistate to make OSyncChange OSyncData more complex ... since you
could perfeclty use this function without capabilities and stuff like that.

This would als require to break the API.


>
> It would then boil down to modifying functions like osync_objformat_compare
>  to take capabilities into account (not trivial).
>
> As far as I can see, this would be a far more efficient solution.


And i don't see the advantage of performance here? You would then end up again
in calling osync_obj_engine_clone_and_demerge .. .but jsut in a different
place.

I guess if you want to reduce the numbers of clone and demerges then you need
to work higher in the stack ... e.g. at the place where
_osync_obj_engine_clone_and_dmerge gets called today ... and try to demerge
every change only once and reuse it until a mapping got found.

>
> The drawback is of course that it needs coding work (=time).
>
> However, as demerge_xmlformat needs heavy work anyway, I think this may be
>  a good time to consider replacing clone-demerge-compare with a compare
>  taking capabilities into account.
>
> What do you all think about this proposal?

I guess we should post-pone this ... this is "just" a perforamance
improvments, which we could still do later without breaking the API. Currently
we should concentrating in getting things working ASAP, before making them
fast ... later we can still think about how to make synchronization work with
O(1) ;)

>
> /Henrik
>
> PS: This was about demerge. I have not quite figured merge out, maybe
>  somebody more knowledgeable than me could comment on this...

Merge is currently not active (due to API changes, trivial porting required.)
But the merge process is less complex, since you don't have to deal with
different combination of capabilities and changes/data.

Best Regards,
Daniel

--
Daniel Gollub                        Geschaeftsfuehrer: Ralph Dehner
FOSS Developer                       Unternehmenssitz:  Vohburg
B1 Systems GmbH                      Amtsgericht:       Ingolstadt
Mobil: [phone]         Handelsregister:   HRB 3537
EMail: gollub@...          http://www.b1-systems.de

Adresse: B1 Systems GmbH, Osterfeldstraße 7, 85088 Vohburg
http://pgpkeys.pca.dfn.de/pks/lookup?op=get&search=0xED14B95C2F8CA78D


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Opensync-devel mailing list
Opensync-devel@...
https://lists.sourceforge.net/lists/listinfo/opensync-devel