tree 9a9c96ebd91f19dc696207da16c3805632fe080c
parent b6be51bd6eba2710608ae787573b73e266832ca8
author Philip Langer <planger@eclipsesource.com> 1516704728 +0100
committer lgoubet <laurent.goubet@obeo.fr> 1525347727 +0200

Improve performance of ComparisionUtil

For CASCADING_DIFF, it's best to do the cheapest test first.

For getSubDiffs there is an inner guard for if
(ofKind(MOVE).apply(diff)) that results in subDiffs being an empty
iterable. In this case, nothing is added to processedDiffs and
getAssociatedDiffs will return an empty iterable as well, so the overall
result is an empty set.  The guard against processing a MOVE diff is
cheap and should be first, to avoid computing a matchOfValue that's not
needed anyway.  In fact it's not needed until we confirm the reference
change is for a containment. Also, when the matchOfValue is null, the
result will be an empty iterable so no point in doing any memory
allocation or other computations in this case.

In getAssociatedDiffs, a new reqs hash set is created, just so that
diffRoot can be removed, before set  is added to the associatedDiffs.
It's far cheaper to add all the reqs and to remove the diffRoot without
creating an intermediate set. Also we could avoid proxy resolution to
make it even more efficient. We can do that with all the feature values.
The final loop of this can avoid repeatedly calling getSubDiffs because
that is a loop invariant.

In getExpectedSide we should avoid doing computation that are only
needed for a three way match comparison.

Change-Id: Id39ada3bc2b095c8916083e0b2106a9fa79a3f1b
Signed-off-by: Philip Langer <planger@eclipsesource.com>