geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Frankie Lam" <fra...@mindless.com>
Subject Re: Reflection Bad, OO and direct Method invocation Good...
Date Sat, 09 Aug 2003 13:22:33 GMT
I fully agree with you and the benchmark you made is really persuasive =)
I would like to raise a point that the disadvantages of reflection are more
apparant when the methods are called frequently. JBoss CMP implementation
is, AFAIK, reflection-based and its performance is really disappointing. I'd
prefer some sort of on-the-fly compilation mechanisms that need to be done
once only instead.

Best regards,
  Frankie

----- Original Message -----
From: John C. Dale
To: geronimo-dev@incubator.apache.org
Sent: Saturday, August 09, 2003 9:16 PM
Subject: Reflection Bad, OO and direct Method invocation Good...


I'm concerned about your mention of reflection.  I really like reflection,
and think it has many useful applications in the application development
space, but should be kept out of any runtime application that has stringent
scalability and performance requirements.  Although reflection allows an
incredibly generic way to solve many difficult problems, and really opens
the door to completely grandios perfectly idealistic genericititousness ;)
, a straight-forward OO approach to solving the problems would 1) be faster
and 2) be easier to read and maintain.  I've seen reflection based
approaches work, and I've seen them bomb.

One might argue that in a container based system that will eventually
support clustering and scalability doesn't have to worry about savoring
individual CPU cycles that might be expended needlessly with a
reflection-based design.  Just add more hardware and the user experience
will be perpetually preserved.  I would argue, however, that the development
community will be able to make better use of the product if the rate at
which additional hardware purchases becomes necessary decreases.  The
philosophy, IMHO, should be to solve the problems at hand with
straight-forward OO solutions, and not to focus so much on being generic and
supporting n * infinity solutions up-front.  Using things like the
Policy/Strategy pattern at well-selected locations will afford the
opportunity for pluggability without compromising maintainability and
performance.

Here are some dramatic results:

Direct:

public void init()
{
   customer = new Customer();
}

public void run()
{
   customer.work();
}

Interface (Polymorphism):

public void init()
{
  customer = new Customer();
}
public void run()
{
  Person person = (Person) customer;
  person.work();
}

Reflection:

public void init()
{
  customer = new Customer();
  try
  {
      method = customer.getClass().getMethod("work", new Class[0]);
  }
  catch (Exception e)
  {
  }

   params = new Object[0];
}

public void run()
{
  try
  {
    method.invoke(customer, params);
  }
  catch (Exception e)
  {
  }
}

With 1000000 of the above code, here were the results:

JDKDirectTestInterfaceTestReflectionTest
Sun 1.452 ms54 ms543 ms
Sun 1.4 -server26 ms56 ms279 ms
Sun 1.3124 ms128 ms2168 ms
Sun 1.3 -server41 ms58 ms2012 ms
IBM 1.375 ms78 ms2134 ms

Reflection will significantly effect the performance of the system and
should be avoided for any runtime operations.  Where it should and could
definitely be applied is with the dynamic generation and compilation of
code, or generation of metadata.  Otherwise, even at the recommendation of
Sun, it should be avoided for runtime operations.

Best,

John C. Dale




Mime
View raw message