Community
Participate
Working Groups
Startup of the e4 compatibility app: Called, times Startup time spent in, % EMFModelDeltaThreeWayDelayedSet.getAttributeValue() 3 95% XMLModelReconciler.threeWayMerge() 3 95% XMLModelReconciler.getPosition() 950 95% EcoreEList.indexOf(Object) 940,000 95% EcoreEList.resolveProxy(EObject) 470,000,000 70% EObjectImpl.eIsProxy() 470,000,000 25%
This is like both funny and sad at the same time.
I fixed bug 312454 which should probably have helped this a bit.
Much better now, down to 20 million calls on restarting cleaned workspace: EMFModelDeltaThreeWayDelayedSet.getAttributeValue() 4 30% XMLModelReconciler.threeWayMerge() 4 30% XMLModelReconciler.getPosition() 700 30% EcoreEList.indexOf(Object) 41,000 30% EcoreEList.resolveProxy(EObject) 20,000,000 20% EObjectImpl.eIsProxy() 20,000,000 6% This is on a clean workspace + create a "Hello World" project + restart -> this restart is measured. Similar picture on the second restart.
(In reply to comment #3) > Much better now, down to 20 million calls on restarting cleaned workspace: That's better than I expected. This is probably because of a 3-way merge on 495/497/495 commands. Since the ordering of commands don't actually matter, there should be no reason to call indexOf(Object) on the List. So it may be possible for me to optimize the code by ignoring things that don't need to be ordered (handlers, commands, ...?). Thanks for checking, Oleg.
(In reply to comment #4) > Since the ordering of commands don't actually matter, > there should be no reason to call indexOf(Object) on the List. So it may be > possible for me to optimize the code by ignoring things that don't need to be > ordered (handlers, commands, ...?). I haven't actually implemented this optimization but I corrected a small conditional check in merging logic that was assuming some things about how Collections worked (which fail when using EMF implementations due to proxies). The number of indexOf(Object) calls should now be down significantly.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
This is a mass change to close all e4 bugs marked with "stalebug" whiteboard. If this bug is still valid, please reopen and remove the "stalebug" keyword.
