Long time ago, I was creating a mini ORM using reflection.
While reading about reflection I got a similar answer like this:
Java Reflection Performance
Which makes completely sense and I quit my mini orm and sharpen my CTRL+C, CTRL+V keys ( the lib was intended to avoid having to rewrite again and again the same snippets for different tables in a web app I was working on )
Years later for some reason I don't remember now ( nor want to remeber ) I was reading ( or trying to... ) the Hibernate source code, for I wanted to know if they use AOP to generate code on the fly and avoid the reflection penalty, but for my surprise, all of what I saw was pure reflection.
Does it mean the most accepted ORM framework out there, did exactly what years before discourage me from continuing my naive efforts ?? :")
My question is: Can someone confirm my understanding of the Hibernate implementation? Do they generate bytecode on the fly to improve performance? Or are we ( when we use it ) always paying the reflection penalty ( which by the way, if the diff is in some ms, none of us have noticed nor complained about )
Are we paying the reflection penalty? If we are, I think it is worth it!!!
Regards.
Hibernate instruments your models to be hibernate aware.
There are varying levels of cost for using Reflection. Constantly looking up a method for a particular class is particularly expensive. Executing a method via reflection using a cached copy is not that much slower. If one thinks of the tasks that the reflection api must complete to invoke the method it all makes sense which each part is slow and consumes cpu cycles.
Locating a method
Visit each and every method of a particular class
Test each methods visibility, method signature etc.
Generate bytecode for found method.
One factors in the numbers of methods in a typical class and that some of these operations arent trivial it becomes obvious that this can be costly.
Invoking the method.
Each reflected method amounts to a bit of byte code that invokes the target method with a bit of boilerplate to match the reflection interface. Before it can do that it must perform some sanity checks so it can complain with nice messages rather than letting the runtime throw ClassCastException and similar exceptions.
If an instance method check the instance passed in isnt null and is the right type.
Check the arguments parameter includes the right amount and type of parameters.
Execute the method within a try catch. In the catch throw ITE etc.
All these extras add some cost - not a lot but it does make things slower.
Runtime costs
In general caching methods and invoking that isnt cost but is a bit slower. The reflection api itself does attempt to cache methods and classes but finding the right method and so on is still a slow operation.
I think the important thing to remember is the relative cost in the overall application. Is reflection slower then normal object creation? Yes. Has reflection got better and faster? Yes. But really these points aren't very important when comparing the cost of reflection versus going over the wire and doing something with the database, which is what hibernate does - the cost becomes completely negligible and I'd say we are not paying the price.
The cost of persistence and retrieval is many times the cost of reflection. To access a record from a DB might take 1-10 ms and to construct an object with reflection might take 0.001 to 0.01 ms.
Doesn't NHibernate cache the class info gathered through reflection so you only pay the penalty the first time?
You really pay the reflection penalty by using NHibernate but its extensibility allow you to avoid 90% of them if you provide all optimized reflection implementation via NHibernate.Bytecode.IBytecodeProvider.
Related
I have bean util library and we cache Method/Fields of properties, of course. Reading and writing goes via reflection.
There is an idea to skip reflection and for each method/field to bytecode-generate a simple object that directly calls the target. For example, if we have setFoo(String s) method, we would call a set(String s) method of this generated class that internally calls setFoo(). Again, we are replacing the reflection call with the runtime generated direct call.
I know Java does similar thing with GeneratedMethodAccessor. But it's cache may be limited by JVM argument.
Does anyone know if it make sense to roll-on my implementation, considering the performance? On one hand, it sounds fine, but on other, there are many new classes that will be created - and fill perm gen space.
Any experience on this subject?
You are trying to re-invent cglib's FastMethod
In fact, Reflection is not slower at all. See
https://stackoverflow.com/a/23580143/3448419
Reflection can do more than 50,000,000 invocations per second. It is unlikely to be a bottleneck.
Edit 2:
Does a program with a fully object-oriented implementation give high performance? Most of the framework is written with full power of it. However, reflection is also heavily used to achieve it like for AOP and dependency injection. Use of reflection affects the performance to a certain extent.
So, Is it good practice to use reflection? Is there some alternative to reflection from programming language constructs? To what extent should reflection be used?
Reflection is, in itself and by nature, slow. See this question for more details.
This is caused by a few reasons. Jon Skeet explains it nicely:
Check that there's a parameterless constructor Check the accessibility
of the parameterless constructor Check that the caller has access to
use reflection at all Work out (at execution time) how much space
needs to be allocated Call into the constructor code (because it won't
know beforehand that the constructor is empty)
Basically, reflection has to perform all the above steps before invocation, whereas normal method invocation has to do much less.
The JITted code for instantiating B is incredibly lightweight.
Basically it needs to allocate enough memory (which is just
incrementing a pointer unless a GC is required) and that's about it -
there's no constructor code to call really; I don't know whether the
JIT skips it or not but either way there's not a lot to do.
With that said, there are many cases where Java is not dynamic enough to do what you want, and reflection provides a simple and clean alternative. Consider the following scenario:
You have a large number of classes which represent various items, i.e. a Car, Boat, and House.
They both extend/implement the same class: LifeItem.
Your user inputs one of 3 strings, "Car", "Boat", or "House".
Your goal is to access a method of LifeItem based on the parameter.
The first approach that comes to mind is to build an if/else structure, and construct the wanted LifeItem. However, this is not very scalable and can become very messy once you have dozens of LifeItem implementations.
Reflection can help here: it can be used to dynamically construct a LifeItem object based on name, so a "Car" input would get dispatched to a Car constructor. Suddenly, what could have been hundreds of lines of if/else code turns into a simple line of reflection. The latter scenario would not be as valid on a Java 7+ platform due to the introduction of switch statements with Strings, but even then then a switch with hundreds of cases is something I'd want to avoid. Here's what the difference between cleanliness would look like in most cases:
Without reflection:
public static void main(String[] args) {
String input = args[0];
if(input.equals("Car"))
doSomething(new Car(args[1]));
else if(input.equals("Boat"))
doSomething(new Boat(args[1]));
else if (input.equals("House"))
doSomething(new House(args[1]));
... // Possibly dozens more if/else statements
}
Whereas by utilizing reflection, it could turn into:
public static void main(String[] args) {
String input = args[0];
try {
doSomething((LifeItem)Class.forName(input).getConstructor(String.class).newInstance(args[1]));
} catch (Exception ie) {
System.err.println("Invalid input: " + input);
}
}
Personally, I'd say the latter is neater, more concise, and more maintainable than the first. In the end its a personal preference, but that's just one of the many cases where reflection is useful.
Additionally, when using reflection, you should attempt to cache as much information as possible. In other words employ simple, logical things, like not calling get(Declared)Method everywhere if you can help it: rather, store it in a variable so you don't have the overhead of refetching the reference whenever you want to use it.
So those are the two extremes of the pro's and con's of reflection. To sum it up if reflection improves your code's readability (like it would in the presented scenario), by all means go for it. And if you do, just think about reducing the number of get* reflection calls: those are the easiest to trim.
While reflection is most expensive than "traditional code", premature optimization is the root of all evil. From a decade-long empirical evidence, I assume that a method invoked via reflection will hardly affect performance unless it is invoked from a heavy loop, and even so there have been some performance enhancements on reflection:
Certain reflective operations, specifically Field, Method.invoke(),
Constructor.newInstance(), and Class.newInstance(), have been
rewritten for higher performance. Reflective invocations and
instantiations are several times faster than in previous releases
Enhancements in J2SDK 1.4 -
Note that method lookup (i.e. Class.getMethod) is not mentioned above, and choosing the right Method object usually requires additional steps such as traversing the class hierarchy while asking for the "declared method" in case that it is not public), so I tend to save the found Method in a suitable map whenever it is possible, so that the next time the cost would be only that of a Map.get() and Method.invoke(). I guess that any well-written framework can handle this correctly.
One should also consider that certain optimizations are not possible if reflection is used (such as method inlining or escape analysis. Java HotSpot™ Virtual Machine Performance Enhancements). But this doesn't mean that reflection has to be avoided at all cost.
However, I think that the decision of using reflection should be based in other criteria, such as code readability, maintainability, design practices, etc. When using reflection in your own code (as opposed to using a framework that internally uses reflection), one risk transforming compile-time errors into run-time errors, which are harder to debug. In some cases, one could replace the reflective invocation by a traditional OOP pattern such as Command or Abstract Factory.
I can give you one example (but sorry, I can't show you the test results, because it was few months ago). I wrote an XML library (custom project oriented) which replaced some old DOM parser code with classes + annotations. My code was half the size of the original. I did tests, and yes, reflection was more expensive, but not much (something like 0.3 seconds out of 14-15 seconds of executing (loss is about 2%)). In places, where code is executed infrequently, reflection can be used with a small performance loss.
Moreover, I am sure, that my code can be improved for better performance.
So, I suggest these tips:
Use reflection if you can do it in a way that is beautiful, compact & laconic;
Do not use reflection if your code will be executed many-many times;
Use reflection, if you need to project a huge amount of information from another source (XML-files, for example) to Java application;
The best usage for reflections and annotations is where code is executed only once (pre-loaders).
I'm writing code in the Java ME environment, so speed is absolutely an important factor. I have read several places that reflection of any sort (even the very limited amounts that are allowed on java ME) can be a very large bottleneck.
So, my question is this: is doing String.class.getName() slow? What about myCustomObject.getClass().getName()? Is it better to simply replace those with string constants, like "java.lang.String" and "com.company.MyObject"?
In case you're wondering, I need the class names of all primitives (and non-primitives as well) because Java ME does not provide a default serialization implementation and thus I have to implement my own. I need a generic serialization solution that will work for both communication across the network as well as local storage (RMS, but also JSR-75)
Edit
I'm using Java 1.3 CLDC.
String.class.getName() would be not slow because its value will be loaded before executed.i.e compiler will put its value before line will execute.
myCustomObject.getClass().getName() would be bit slower then previous as it will be retrieved at time for execution
Reflection is not unnaturally slow; it's just as slow as you'd expect, but no slower. First, calling a method via reflection requires all the object creation and method calling that is obvious from the reflection API, and second, that if you're calling methods through reflection, Hotspot won't be able to optimize through the calls.
Calling getClass().getName() is no slower than you'd expect, either: the cost of a couple of virtual method calls plus a member-variable fetch. The .class version is essentially the same, plus or minus a variable fetch.
I can't speak for Java ME, but I'm not surprised at the overhead by using reflection on a resource constrained system. I wouldn't think it is unbearably slow, but certainly you would see improvements from hard-coding the names into a variable.
Since you mentioned you were looking at serialization, I'd suggest you take a look into how its done in the Kryo project. You might find some of their methods useful, heck you might even be able to use it in Java ME. (Unfortunately, I have no experience with ME)
Suppose I have an interface with lots of methods that I want to mock for a test, and suppose that I don't need it to do anything, I just need the object under test to have an instance of it. For example, I want to run some performance testing/benchmarking over a certain bit of code and don't want the methods on this interface to contribute.
There are plenty of tools to do that easily, for example
Interface mock = Mockito.mock(Interface.class);
ObjectUnderTest obj = ...
obj.setItem(mock);
or whatever.
However, they all come with some runtime overhead that I would rather avoid:
Mockito records all calls, stashing the arguments for verification later
JMock and others (I believe) require you to define what they going to do (not such a big deal), and then execution goes through a proxy of various sorts to actual invoke the method.
Good old java.lang.reflect.Proxy and friends all go through at least a few more method calls on the stack before getting to the method to be invoked, often reflectively.
(I'm willing to be corrected on any of the details of those examples, but I believe the principle holds.)
What I'm aiming for is a "real" no-op implementation of the interface, such as I could write by hand with everything returning null, false or 0. But that doesn't help if I'm feeling lazy and the interface has loads of methods. So, how can I generate and instantiate such a no-op implementation of an arbitrary interface at runtime?
There are tools available such as Powermock, CGLib that use bytecode generation, but only as part of the larger mocking/proxying context and I haven't yet figured out what to pick out of the internals.
OK, so the example may be a little contrived and I doubt that proxying will have too substantial an impact on the timings, but I'm curious now as to how to generate such a class. Is it easy in CGLib, ASM?
EDIT: Yes, this is premature optimisation and there's no real need to do it. After writing this question I think the last sentence didn't quite make my point that I'm more interested in how to do it in principle, and easy ways into dynamic class-generation than the actual use-case I gave. Perhaps poorly worded from the start.
Not sure if this is what you're looking for, but the "new class" wizard in Eclipse lets you build a new class and specify superclass and/or interface(s). If you let it, it will auto-code up dummy implementations of all interface/abstract methods (returning null unless void). It's pretty painless to do.
I suspect the other "big name" IDEs, such as NetBeans and Idea, have similar facilities.
EDIT:
Looking at your question again, I wonder why you'd be concerned about performance of auto proxies when dealing with test classes. It seems to me that if performance is an issue, you should be testing "real" functionality, and if you're dealing with mostly-unimplemented classes anyway then you shouldn't be in a testing situation where performance matters.
It would take a little work to build the utility, but probably not too hard for basic vanilla Java interface without "edge cases" (annotations, etc), to use Javassist code generation to textually create a class at runtime that implements null versions of every method defined on the interface. This would be different from Javassist ProxyFactory (Or CGLib Enhancer) proxy objects which would still have a few layers of indirection. I think there would be no overhead in the resulting class from the direct bytecode generation mode. If you are brave you could also dive into ASM to do the same thing.
A related post here pretty much established reflection in Java as a performance hog. Does that apply to the CLR as well? (C#, VB.NET, etc).
EDIT: How does the CLR compare to Java when it comes to reflection? Was that ever benchmarked?
I wouldn't really care about the instantiation performance of the object using reflection itself but the actual performance of methods and such since those are after all what I'll be using from the class anyway.
Surely the instantiation takes a lot of time as can be seen in the linked post but since you're most likely using the object's methods instead of just instantiating it, you shouldn't worry too much about reflection performance - as long as you're not doing the method calls by invoking reflected Method objects!
Besides you only need one reflected instance of the object, use .clone() and other clever tricks if you need to create more copies.
Yeah, reflection in .NET is a performance intensive operation too as it requires querying metadata tables in assemblies.
The default implementation of Equals for value types is implemented using Reflection. It works, but it is darn slow and it is easy to implement a specific version, which is much faster (the catch is that you have to implement GetHashCode as well). How much faster depends on the actual value type of course, but I have seen some huge boosts here.