[picocontainer-scm] [jira] (PICO-395) Optimization for DefaultPicoContainer.getInstance
"Chris Simmons (JIRA)" <jira-yCVjj/[email protected]> Thu, 25 Apr 2013 04:40:52 -0500 (CDT)
| Newsgroups | gmane.comp.java.picocontainer.cvs |
|---|---|
| Message-ID | <JIRA.145760.1366882791448.23978.1366882852825@codehaus01.managed.contegix.com> |
Chris Simmons created PICO-395 Optimization for DefaultPicoContainer.getInstance Issue Type: Improvement Affects Versions: 2.14.1 Assignee: Paul Hammant Components: PicoContainer (Java) Created: 25/Apr/13 4:39 AM Description: This method DefaultPicoContainer.getInstance() currently does this getModifiableComponentAdapterList().contains(componentAdapter); which involves scraping over an array. This is rather slow for a big container and is proving to be a bottleneck in our application. If you have n containers being instantiated then you'll do contains n times on a list o which will be o(n^2) calls to equals. Two simple fixes spring to mind: - Keep the component adapters in a set instead - if you use a linked hash set then you'd get exactly the same iteration order but contains() will be fast. - Use the keyToAdapterCache map instead like so: getComponentKeyToAdapterCache().get(componentAdapter.getComponentKey()) == componentAdapter A more involved alternative might be to admit that a given ComponentAdapter needs to know its parent PicoContainer and hence keep a back-reference so you could do componentAdapater.getPicoContainer() == this. Project: PicoContainer Priority: Major Reporter: Chris Simmons This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira ---------- To unsubscribe from this list please visit: http://xircles.codehaus.org/manage_email