I have an application that utilizes a Provider Pattern. The application utilizes the provider implementation by calling interfaces that are defined by the application.
I'm currently researching ways I can optimize my application around interface calls.
I can limit the complexity of my application to the following:<ol><li>I only need to load the implementation dynamically once on start-up</li> <li>I only need one provider implementation for a particular set of interfaces for an application instance at any one time.</li> </ol>
I would appreciate any strategies people have put into practice to:<ol><li>Reducing interface calls</li> <li>Any tricks to generically call the interface implementation classes directly.</li> <li>Various ways to take better advantage of any compiler optimizations. </li> </ol>
Some mis-conceptions worth addressing here.<ol><li>
You can reduce interface calls by calling the underlying concrete implementations directly (or using abstract classes) You should do this when it simplifies the design and improves maintainability (usually <strong>more</strong> interfaces helps, but not always)</li> <li>
You can cast an interface reference to a concrete reference and use that instead. This is generally bad programing practice and has little impact on performance. Generally you only do this when refactoring properly is more work than its worth. (Its not a good design approach but can be a pragmatic one)</li> <li>
<em>The compiler doesn't optimize the code in any significant way</em>. The few optimizations it does (such as inlining compile time constants) you could probably do without. The JVM does the useful optimizations at runtime. Second guessing what the JVM will do and try to optimise your code is a trail and error process. If you try 10 things which you think should help, 1 will make it significantly faster, 6 will make little difference and 3 will make it slower. i.e. simple code tends to be optimized best.</li> </ol>
Unlike C++, most JVMs can optimise out the cost of virtual functions, esp when there is only one or two implementations actually used. i.e. it can optimise code based on how it is used rather than what the compiler can staticly determine.Answer2:
By the sound of it you're doing it the wrong way around.<ol><li>
Well-designed interfaces reduce and not increase application complexity. The interfaces typically used with a provider should help compartmentalise the system. If you feel it would be simpler to access the implementation directly then it's possible that your interfaces need to be redesigned.</li> <li>
The runtime overhead of an "interface call" is so minuscule that you're unlikely to ever be in a situation where it makes the difference between a working and a non-working system.</li> <li>
Generally speaking the Java compiler itself does very little optimisation. The bulk of it happens runtime and therefore the more "natural" your code is, the better the JIT compiler will deal with it. If you try to play tricks to force this optimisation or that (like manually inlining code or reusing variables), you're likely to end up with slower code.</li> </ol>
To sum it up; if you want to reduce the complexity of the application, make sure your modules are separated where they should be (the fewer inter-module dependencies you have, the better) and use a code analyser tool to keep track of complexity metrics.