Menu
▾
▴
opensync-devel
|
From: Henrik /K. <he...@ka...> - 2009-10-24 14:13:46
|
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... |
|
From: Daniel G. <go...@b1...> - 2009-10-29 14:22:52
|
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 |
Thanks for helping keep SourceForge clean.
X