Bug 501713 - Inefficient implementation of org.eclipse.sphinx.emf.util.EObjectUtil.deproxify(EObject)
Summary: Inefficient implementation of org.eclipse.sphinx.emf.util.EObjectUtil.deproxi...
Status: CLOSED WONTFIX
Alias: None
Product: Sphinx
Classification: Automotive
Component: Core (show other bugs)
Version: 0.11.0   Edit
Hardware: PC Windows NT
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-19 08:19 EDT by Andreas Graf CLA
Modified: 2024-05-06 23:29 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Graf CLA 2016-09-19 08:19:33 EDT
org.eclipse.sphinx.emf.util.EObjectUtil.deproxify(EObject) has the following fragment:

for (Iterator<EObject> iter = eObject.eAllContents(); iter.hasNext();) {
				deproxify(iter.next());
}

Which means that it invokes the same function for its entire subtree.
That means that the subtree again invokes all of it subtrees, resulting in exponential runtime.

I think we have to alternatives:

Either use eContents, which will use recursion to iterate through the tree

		for (Iterator<EObject> iter = eObject.eContents(); iter.hasNext();) {
				deproxify(iter.next());
			}

or invoke the unsetting inline: 



for (Iterator<EObject> iter = eObject.eAllContents(); iter.hasNext();) {
		if (eObject != null) {
			// Deproxify given EObject
			if (eObject.eIsProxy() && eObject instanceof InternalEObject) {
				((InternalEObject) eObject).eSetProxyURI(null);
			}
}
}

I'd go for the 2nd and would expect performance improvements when shifting around huge models.

BTW, proxify does not seem to need a fix (uses recursion).
Comment 1 Balazs Grill CLA 2024-05-06 23:29:22 EDT
Closed stale issue before migration