Community
Participate
Working Groups
Verifying N20100904-2000 build, it appears that most of the OSGI perf tests got a big regression, except StatePerformanceTest#testCreation(). This first time the regression appeared was on build N20100828-2000 but it seems that for some tests, it was on later build. I do not open different bugs but if there are several origin please feel free to split this bug into several ones (including me in cc thx).
One possible cause of the regression is the change to org.eclipse.osgi.internal.module.MappedList<K, V> to use Array.newInstance to create properly typed arrays. I will have to test to see if that is the case. If so then we should consider changing the internal class to use generified List instead of typed arrays.
Another cause might be bug 323012.
Perhaps, I was going to wait to do more analysis until after we start compiling with the new compiler. In this case (resolver slowdown) I have my doubts. Quite a bit if changes went into the resolver to implement generic capability/requirement (RFC 154). I would not be surprised if this slowed us down some. Although the current numbers are more than I would expect.
Created attachment 181204 [details] degredation comment test patch This slowdown is not related to bug323012. I have tracked down the slowdown for all the resolution tests (all test except testStoreAndRetrieve) to the changes required for bug323296. At first I thought it was because of the changes mentioned in comment 1 about the use of Array.newInstance. While that can be slow, I modified MappedList a while back in bug324774 to use types of List<V> instead of arrays V[] which removed the calls to Array.newInstance. This has not helped speed things up. The tests do a large amount of resolution loops. before bug323296 we could easily iterate over a simple array type for all the suppliers. But the introduction of resolver hooks in bug323012 has forced us to create Collections of capabilities to pass the resolver hooks. We must pre-filter these collections to remove any capabilities that do not match the constraint. This adds an extra loop where we iterate over and manipulate the Collection to remove non-matching candidates before passing the collection to any registered hooks. This extra step to create an iterator and additional looping contributes to the overall regression for the resolver. Since we must use Collections to pass the ResolverHook it is much better to use the Collection construct in the code, to do otherwise likely will only add even more overhead. I am going to mark up the resolution tests with a degradation statement in 3.7 and point to this bug. The testStoreAndRetrieve degradation is because of bug323427. There is extra data for each generic capability which requires more time to read and write the data. I will add a degradation comment to that test also.
Patch released.
