On Tue, Feb 22, 2011 at 1:05 PM, Patricia Shanahan <[email protected]> wrote:
We won't always be able to integrate an experiment with its proper package > until after the experiment has been done. > > For example, my recent FastList changes involved a change in how a FastList > user scans the list, from one based on list.head() and node.next() to making > FastList Iterable. I did not do the changes to the rest of outrigger to > compile with the new interface until after I had assured myself that at > least one Iterable implementation was as fast as the old implementation. > > I'm also dubious about doing performance comparisons with different > environments for the code being compared. My ideal is a program that can > cycle among implementations in a single run. Next best is a program that > measures a run-time selected implementation, but with everything except the > code under test unchanged. Everything involved must be built with the same > compiler version and parameters, so I strongly prefer a single build. > > I'm not sure how all these issues would be handled in the modular build > environment. I'm also not sure how a modular build environment would deal with this. For what it's worth though, given that one can specify real java objects in the configuration, you might consider defining an interface for the desired utility that your different implementations will implement; and then have your test/benchmark retrieve from the configuration, the particular implementation(s) you wish to use. With respect to Outrigger's use of FastList, you could also eventually modify Outrigger to retrieve a FastList implementation from its configuration (or use a default if no configuration exists, or no FastList entry is specified in the configuration), rather than instantiating the utility class as it does now. If you look at some of the config files provided with the hello example, you'll see examples of things like a discovery manager or a service discovery manager being configured. Configuring a FastList implementation can be done in a similar fashion; for example, <...>/com/sun/jini/example/hello/config/client.config <...>/com/sun/jini/example/hello/config/jeri-server.config It's just a thought, though. If I've misunderstood what you want to accomplish, I apologize. Brian
