river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Murphy <btmurphy....@gmail.com>
Subject Re: Benchmark organization
Date Tue, 22 Feb 2011 18:51:36 GMT
On Tue, Feb 22, 2011 at 1:05 PM, Patricia Shanahan <pats@acm.org> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message