| [EMF Compare] Scalability issues on GenericDiffEngine.getMatchedEObject(EObject) & AbstractC [message #695838] |
Tue, 12 July 2011 16:03  |
Eclipse User |
|
|
|
Originally posted by:
Hi folks,
we've been studying to implement some client use-cases reusing EMF
Compare to determine differences between 2 models stored in a CDO Server.
Among several other issues yet to study, I've face scalability issues
with GenericDiffEngine.getMatchedEObject(EObject) and
AbstractCheck.getMatchedEObject(EObject).
org.eclipse.emf.compare.diff.engine.GenericDiffEngine.getMatchedEObject(EObject)
org.eclipse.emf.compare.diff.engine.check.AbstractCheck.getMatchedEObject(EObject)
org.eclipse.emf.compare.diff.engine.check.AbstractCheck.isUnmatched(EObject)
Both method implementations (which are, by the way, duplicated) do use
CrossReferencing to determine which EObjects have been matched during
the Match stage. It seems to me that using CrossReferencing to do this
may be convenient when objects are in memory, but definitely not when
objects are stored remotely. And even when objects are in memory, using
CrossRefercing seems like a bit of overhead. While doing some profiling,
I found it was called dozens (if not hundred) of times per second.
Hacking a bit the code I found its way faster (and probably would have a
negigible effect over memory footprint) to have a "match cache".
Something like:
protected Map<EObject, EObject> matches;
and then getMatched would look like this:
protected final EObject getMatchedEObject(EObject from) {
return matches.get(from);
}
Havent used it, but probably that would need some refinement to work in
a Three Way Comparison scenario, I guess.
This seem to work very well to me. I decided to extend and contribute my
own GenericMatchEngine and AttributesCheck/ReferencesCheck
implementation, overriding those getMatchedEObject methods, but as you
already see, those are declared as final.
Using JDT a bit reveals that this getMatchedEObject is used very much in
each class (used in 11 methods at GenericDiffEngine), and it also seems
to me very much important to leave it unextensible / replaceable.
I would like to ask if it would be feasible to have some intermediate
interface, something like "MatchManager" which takes care of this.
The default implementation will use CrossReferencing, but users could
contribute different MatchManager implementations. Don't care about the
implementation specifics as long as this becomes pluggable /
replaceable. Also, locate this concern in a single place, and you'll get
rid of duplicate code :)
Would like to hear you opinion.
Cheers,
Víctor.
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02796 seconds
] 
Search
Help
Register
Login
Home
