Community
Participate
Working Groups
Build Identifier: 3.6.1r361_v20100827 There is a performance regression in Eclipse 3.6.1 against 3.4.2 in the OSGI framework Event Manager, the details are: New Time from: 3.6.1r361_v20100827 Old Time from: 3.4.2.R342_v20090122 From Eclipse 3.4.2: org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventListeners$ListElement[], EventDispatcher, int, Object), To 3.6.1: org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(Set, EventDispatcher, int, Object) Reproducible: Always Steps to Reproduce: 1.Open Eclipse with WTP 2.Open and close DD (for any web.xml) 4 or more times 3.There is a regression in the response time.
Created attachment 180064 [details] Screenshot from the profiling results There is a regression in the process greater than 100%.
Created attachment 180075 [details] Performance improvement to CopyOnWriteIdentityMap for iterating over entry set The org.eclipse.osgi.framework.eventmgr was rewritten to use collections in Oct 17, 2008 (part of the 3.5 release). The EventListeners type was deprecated and replaced with a Map implementation (CopyOnWriteIdentityMap) whose entry set is used to queue and dispatch events. Lots of code now depends upon the use of Set in the API [ListenerQueue#queueListeners(Set<Map.Entry<K, V>> listeners, EventDispatcher<K, V, E> dispatcher)]. So there is no way to revert back to the old EventListener type and iterate over its contained array. You must be doing a massive amount of event dispatching as the picture shows going from 4 sec to 8 sec. You may want to consider replacing your use of the org.eclipse.osgi.framework.eventmgr package with something more optimized for your needs. Any way, I have attached a patch to CopyOnWriteIdentityMap to improve performance iterating over the entry set which seems to be the performance issue. Can you try this patch out?
Created attachment 180093 [details] Updated patch to correct comments and change base type of value collection. Here is an updated patch. Since this patch improves the existing code in several ways, I am releasing it to HEAD even though this "fix" may not provide sufficient performance gain for the reported scenario.
I don't think the profiling results give us enough data to go on. There are a number of other factors outside of the framework's control that may be at work. Just as a couple of examples: 1) there may be a much larger number of listeners 2) there may be a few listeners that are taking much longer to process the events we fire. We cannot tell from your profile screenshot what the real cause is.
One possible explanation for more calls to EventManager.dispatchEvent is the default enablement of the osgi.bundlefile.limit in 3.5. The osgi.bundlefile.limit option uses EventManager as an implementation detail for firing async events to close bundle files in the background. It would be interesting to see if setting osgi.bundlefile.limit=0 in your config.ini has any effect on the performance numbers.
Closing as worksforme, we need more information to determine if any optimization is needed.
