3

Possible Duplicate:
Why reflection is slow?

It is said, that some parts of reflection does not perform very well. Is that true and which parts of it are considered to perform slow?

Background: I am currently experimenting with a self written persistance layer using reflection. I have done no measurement yet. I just need to know where possible points of optimization are located, so that I can design the program well.

Community
  • 1
  • 1
user573215
  • 4,679
  • 5
  • 22
  • 25
  • Instead of creating your own persistence layer, you may want to consider contributing to one of the many open source ones. – bdoughan Jan 20 '11 at 22:39
  • Reflection is slow compared to....what? What other mechanism are you comparing against introspecting classes and objects? – Jé Queue Jan 20 '11 at 22:43

5 Answers5

3

Most frameworks that use reflection cache the results of the reflective operations so that they do not have to perform them again. So in fact everything happens once, at startup.

Apart from that - all parts are "unperformant". The whole reflection API should be avoided for regular code. For a framework - see the 1st paragraph.

Bozho
  • 588,226
  • 146
  • 1,060
  • 1,140
3

Typically methods invocation works well. Performance problems may be caused by Class.getMethod(), Class.getField(), Class.getDeclaredMethod() etc. Class.forName() is also slow (although it is rather dynamic class loading than reflection).

So, I'd recommend you to cache results of method locating methods, e.g.

Method m = Class.getMethod("foo"); // do it once

// now invoke it as many times as you want

m.invoke(obj);
AlexR
  • 114,158
  • 16
  • 130
  • 208
  • 1
    Can you demonstrate why exactly those methods are slow? My point is, Class.getField() does about the same thing as Map.get does plus some hierarchy traversal, right? Class.getDeclaredFields is even simpler. For me Method.invoke looks much more complicated. Of course, this is just a feeling. – maaartinus Jan 21 '11 at 01:29
  • Thanks for answering. I use getDeclaredFields(). So maybe I'll cache those fields. I will mesure it when I get so far. – user573215 Jan 21 '11 at 18:27
0

The whole point of reflection is to circumvent the type system to do things the language was never intended to do in the first place. So it will be slow no matter what you do.

Reflection allows you to trade-off performance to get a simpler solutions that can be written faster and maintained easier. As soon as you find yourself complicating your code with reflection, you're doing something wrong.

Update

By "simpler", I mean less lines of code. A shorter solution basically. Reflection allows you to abandon type safety to write a shorter, more concise program. This is the rational behind dynamic typing. Java generics gives you a more complex program, but you have type safety. Reflection gives you dynamic typing in a statically typed language. My point was that, if the "reflection" version of your program is more complex than an equivalent "non-reflection" version, then the non-reflection version is superior because it will run faster and be less complicated.

There are other uses of reflection, but metaprogramming isn't really one of them. Metaprogramming is where you write a program that writes another program. For example, lets say you wanted to reformat the names of a large group of files; maybe a collection of wedding photos. A program to do this my look something like:

mv "1bill and fred(kfjw0f3).jpg" "1 - bill and fred.jpg"
mv "2sam and kim(g02fsgsg).jpg" "2 - sam and kim.jpg"
.
.
.

A Ruby program that generates that list of mv commands would be a metaprogram.

Jay
  • 9,314
  • 7
  • 33
  • 40
  • Thanks for answering. I aggree to the first paragraph. I am not sure what you mean by "simpler solution". Isn't it metaprogramming what reflection is all about, so you can create reall generic algorithms? – user573215 Jan 21 '11 at 18:32
0

don't worry. it's very fast. especially in comparison to database operations.

optimizations in a persistence framework like using runtime bytecode generation are ... very odd. we are talking about database here... just use reflection.

PS: a very good and relavant blog article, published today

http://buzdin.blogspot.com/2011/01/is-java-reflection-really-slow.html

irreputable
  • 44,725
  • 9
  • 65
  • 93
-1

Speed mostly comes down to how many instructions need to executed on the processor

(gross oversimplification, but let's run with it for second).

When you call a method, the code can be JIT compiled, giving minimal overhead. You already know what method is going to be called, therefore you know if you're calling it in a valid way, what it returns, what code it needs, etc.

When you do this with reflection, everything goes out the window. You have to try to find the method with a string, then see if you're calling it right, then get all of the code and run it. Usually, none of this can be done beforehand.

This comes back to the difference between static and dynamic:

Static: fast, everything known early, minimal effort necessary at execution time.

Dynamic: Slow, things are figured out later, so things have to be done at run time.

this does not mean reflection is 'bad'!!!!!!!! Speed is NOT the be all and the end all!!!!!

If it saves time and makes things simpler: Do it! If you find out later that you need better performance and the reflection is in the ~20% that is run ~80% of the time, then consider some other solutions. If it was, java would be a very different language and you probably wouldn't be using objects nearly at all. Obviously you should have speed in mind and have some knowledge about reflection, which is exactly why you're asking this question. :D

Gordon Gustafson
  • 40,133
  • 25
  • 115
  • 157