Re: [Opensync-devel] [RFC] Do not clone-demerge-compare, just compare taking capabilities into account

[Daniel G. <go...@b1...>]

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: +49-(0)-160 47 73 970         Handelsregister:   HRB 3537
EMail: go...@b1...          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