• Post Reply Bookmark Topic Watch Topic
  • New Topic

reflection and performance  RSS feed

 
Dave Gress
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
On a large application does the use of Reflection impair performance? We developed an app that will be used by 1000+ users. One thing that was suggested by the client was to:
"Remove application code such as the Reflector class and all reflection-style calls along with their supporting utilities, configuration files and methods. Additionally, remove uses of reflection (supporting utilities, configuration files, and methods) in other portions of the application where it is used to dynamically select objects, methods and parameter lists."
Is this a valid request?
 
David Weitzman
Ranch Hand
Posts: 1365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Welcome to JavaRanch. I can't stress enough the importance of a principle you'll see mentioned again and again in this forum: Profile before you optimize (see the Rules of Optimization). It's almost always a bad idea to rewrite significant portions of your software based on speculation.

If the client can quantitatively prove (using a profiler) that use of reflection is a significant and unacceptable factor in the processing cycles used by the software and that the software isn't running fast enough to meet their needs, go ahead and change it.
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 36441
454
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Dave,
Try to get the client to give you concrete performance requirements. For example, the application must process 100 concurrent queries within 5 seconds. While they can give suggestions, they shouldn't be telling you how to implement code.

Having said that, I think you should try to avoid any unnecessary reflection in production code.
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jeanne Boyarsky:
Having said that, I think you should try to avoid any unnecessary reflection in production code.

Reflection is used more and more in many tools, and it's very useful. I would say first to make sure you're storing the results of reflection for future use as much as possible. Once you've done the lookup, method calls via reflection should perform just as well as direct calls.

Clearly, as stressed above, profile your code so you know what to optimize. I can't count how many times I've been called in to help optimize a chunk of code that turns out to be responsible for less than 1% of the running time while chunks that took over 10% were ignored because they were smaller code blocks.
 
Kris Philippaerts
Greenhorn
Posts: 25
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by David Harkness:
I would say first to make sure you're storing the results of reflection for future use as much as possible.


I agree with David. Furthermore, reflection can definately be used to initialize your application. I.e., at the startup of the application.

So, you shouldn't just throw away all your reflection code. But you should use it with care.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
http://www-106.ibm.com/developerworks/java/library/j-dyn0603/#IDAUVB4 has some interesting numbers on the performance of reflection.

But even if those numbers look persuasive, every performance optimization needs to be done in the light of profiling data of the actual system, or it won't be more than bricolage.
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Dave Gress:
On a large application does the use of Reflection impair performance? We developed an app that will be used by 1000+ users. One thing that was suggested by the client was to: "Remove application code such as the Reflector class and all reflection-style calls [...] Is this a valid request?
No. As stated, it is utter nonsense. Jeanne is absolutely right in pointing out that the client should be giving you their performance requirements and not tell you how to do your job.

My job, by the way, is (among other things) designing and building webapps that have to handle tens of thousands of users generating peak loads of hundreds to over a thousand requests per server a second. Reflection is routinely used even in such high load applications, for example, to introspect request parameters into Java objects[1].

Have another look at those performance figures that Ilja linked to. Sure, method reflection is 70 times slower or so than a straight invocation, so you wouldn't want all your calls to be reflective. But we're not talking about that, are we? According to the same figures, a reflective method call takes about 0.5ms. This is ten times as fast as a network round trip and a hundred times as fast as a database interaction. Unless you have tweaked the hell out of your application but at the same time went overboard on reflection[2], it is unlikely that reflection dominates your performance figures.

The proof of the pudding, though, is in the eating. I can only echo David (both) and Ilja: use a profiler. That will tell you where time is spent. Without a profiler, you're like a blindfolded surgeon rushing the patient straight into the operating theatre and proceeding to make arbitrary incisions in the hope that one of them will catch the affected organ. You're likely to kill rather than cure the patient.

- Peter

[1] Obviously at this volume you wouldn't want to do that with every request; but usually the majority of requests is for R/O data which can be served up straight out of a cache.
[2] To be precise, request time reflection. Reflection in application startup is harmless. In fact the application server already does plenty of it...
[ August 28, 2004: Message edited by: Peter den Haan ]
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 36441
454
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Having said that, I think you should try to avoid any unnecessary reflection in production code.

I just want to clarify that the key word was unnecessary. If something can be done just as easily without reflection, I think it should be. It makes the code easier to read and is faster.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Peter den Haan:
Without a profiler, you're like a blindfolded surgeon rusing the patient straight into the operating theatre and proceeding to make arbitrary incisions in the hope that one of them will catch the affected organ. You're likely to kill rather than cure the patient.


As far as I know, some time ago the first thing a doctor would do if you had sore throat was to remove your tonsils. They aren't that fast doing it today - I don't think it killed many patients, but it obviously wasn't always the best course of action...
 
Warren Dew
blacksmith
Ranch Hand
Posts: 1332
2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Peter den Haan:

Have another look at those performance figures that Ilja linked to. Sure, method reflection is 70 times slower or so than a straight invocation, so you wouldn't want all your calls to be reflective. But we're not talking about that, are we? According to the same figures, a reflective method call takes about 0.5ms. This is ten times as fast as a network round trip and a hundred times as fast as a database interaction.

Er, huh? Half a second for each database interaction sounds awfully long to me. And the article notes that reflection can cause a hit of up to a factor of several thousand in some cases.

I think it's a perfectly reasonable suggestion on the part of the client - especially if the deliverable is source code that the client will be maintaining, rather than the executable. I do agree that the original poster's organization would do well to figure out whether that suggestion is the one that would yield the most benefit for the work involved before implementing it.
 
David Weitzman
Ranch Hand
Posts: 1365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Er, huh? Half a second for each database interaction sounds awfully long to me.

100 * .5 ms = 50 ms = 0.05 seconds, not 0.5 seconds
[ August 27, 2004: Message edited by: David Weitzman ]
 
Stefan Wagner
Ranch Hand
Posts: 1923
Linux Postgres Database Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
My personal test for 1.4/ 1.5 client-server shows for 4M calls:


This is a fast ad-hoc test, which I wouldn't bet on.
Invokation and measurement of the ibm-article might have been very different.
But it shows differences of 1:100 to 1:10 - not 1:1000.
Perhaps because of my testing-scenario, perhaps because of improvements in 1.4.
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stefan Wagner:
My personal test for 1.4/ 1.5 client-server shows for 4M calls...

Were you looking up the method with reflection for each call, or did you look it up at the start and invoke it in the loop?
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Warren Dew:
[...] the article notes that reflection can cause a hit of up to a factor of several thousand in some cases.
Prehistoric JDKs (1.4 has improved reflection performance significantly), reflective field access, etc. I would hope we're not talking about this kind of stuff here.

I think it's a perfectly reasonable suggestion on the part of the client - especially if the deliverable is source code that the client will be maintaining, rather than the executable.
Actually you might well be right. Simply asking for reflection to be removed still strikes me as nonsensical, but it is be reasonable to ask for code that (1) is maintainable and (2) satisfies the performance criteria. I did miss some of the finer points of the original question first time round.

Use of reflection can enhance maintainability significantly but, as noted, can also ruin it. Reflection is used most often in the form of frameworks such as Struts or Spring that use it under the hood. The mention of a Reflector class and so on suggests that Dave et al have effectively been coding some type of framework of their own. Designing and coding a solid framework is hard - as those of us who have been subjected to use in-house frameworks will know - and it's really easy for a badly designed framework to cripple performance and maintainability rather than enhance it. A client demand to remove the framework might in that case be reasonable, simply because the framework is bad, not because reflection in itself is.

Dave, what exactly is that Reflector and so on, and what precisely does your client want to achieve?

- Peter
[ August 28, 2004: Message edited by: Peter den Haan ]
 
Stefan Wagner
Ranch Hand
Posts: 1923
Linux Postgres Database Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David:
 
Jeanne Boyarsky
author & internet detective
Sheriff
Posts: 36441
454
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
David,
I'm not sure what you gain by using reflection here. Am I missing something?
 
D Rog
Ranch Hand
Posts: 472
Linux Objective C Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree, you should include code obtaining a field in loop also. Usually you process a bunch of different objects has no any relations to each other and you would like to set something common in them or get it. In this case you should ger worse result. Anyway, reflection is one and only one thing's keeping me using Java.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!