• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

One important performance related question

 
Ranch Hand
Posts: 154
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi java gurus,
I know that Java allows us to follow OOPS standards like we should have all instance variables declared as private and have getters and setters for encapsulation.
This is all fine, but does'nt this hurt performance.
For Example, let us say I have an application consisting of 1000 instance variables that i set using setter methods and then access those variables using getter methods. It means there would be 2000 method calls for that matter. Will not this hurt performance, or does the java compilere do some kind of inlining.
Like in VB we simply set attributes like TextBox1.value = "Hello"
Please send ur comments on this.
Waiting for some great replies.
 
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Moving this to the Performance forum...
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In most cases, the JVM's JIT compiler inlines the get/set methods at runtime, thus, removing this performance "issue".
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Also, even if it doesn't get fully inlined, a method call typically is quite cheap. If you get performance problems, they are very likely to have different reasons.
But most importantly, in general maintainability is much more important than performance, because of two reasons:
- cpu time is cheap, maintenance is costly, and
- a highly maintainable system is also a highly optimizable system
[ April 14, 2004: Message edited by: Ilja Preuss ]
 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Use bulk accessor if you don't like frequent method call
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Julia Chen:
Use bulk accessor if you don't like frequent method call


FYI, bulk accessors use Value Objects to transfer more than one value with a method call. They are most often used for distributed method calls. In a non-distributed situation, it is very unlikely to buy you noteworthy performance.
 
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
For Example, let us say I have an application consisting of 1000 instance variables that i set using setter methods and then access those variables using getter methods. It means there would be 2000 method calls for that matter. Will not this hurt performance, or does the java compilere do some kind of inlining.
The overhead of calling a method (as opposed to accessing the field value directly) is so small that it can be safely disregarded. For example, in the code below, 1 billion method invocations are performed, and for comparisson, 1 billion of direct accesses to a field are performed. The difference in time? 31.31 seconds for the former and 31.42 seconds for the latter. That is, access by method invocation is actually 10 milliseconds faster. In your case of only a few thousand of calls, the difference would be in a fraction of a microsecond.

[ April 15, 2004: Message edited by: Eugene Kononov ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Eugene, do you get the same results with every run? What if you run them in different order?
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Eugene, do you get the same results with every run?
Yes, very consistent results from multiple runs.
What if you run them in different order?
Great test, -- yes, if I reverse the order (method invocations first, field references second), then the latter is about 300ms faster than the former. I would guess that it has something to do with run time optimizations. Either way, the difference is way too small to be meaningfull. I didn't look at the byte code yet, but I would bet that it is actually the same for both tests (accessing the filed value directly or by method invocation).
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Eugene Kononov:
Great test, -- yes, if I reverse the order (method invocations first, field references second), then the latter is about 300ms faster than the former. I would guess that it has something to do with run time optimizations.


Yes, certainly.


I didn't look at the byte code yet, but I would bet that it is actually the same for both tests (accessing the filed value directly or by method invocation).


Can't possibly be. testMethod could be called on a subclass of PerformanceTest, which could overwrite the accessors.
It's more likely that the Hotspot Engine inlines the method calls at runtime.
 
Wanderer
Posts: 18671
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
[IP]: What if you run them in different order?
[EK]: Great test

It should probably be considered a standard practice that when you compare the performance of two or more methods, you either (a) test them using completely separate JVM invocations, or (b) switch the invocation order to see what effect it has. Typically I do something like this:

Where both A and B are repeating a method several thousand times at least. Generally the times for the first run of both A and B are longer and should be ignored. I look to see if the second and third run of A are roughly equal, and the same for B. If so, then the JVM has probably settled into a steady state for each method, and the times are meaningful. If not, it's probably necessary to increase the number of repetitions.
[ April 18, 2004: Message edited by: Jim Yingst ]
 
John Smith
Ranch Hand
Posts: 2937
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Jim: Where both A and B are repeating a method several thousand times at least. Generally the times for the first run of both A and B are longer and should be ignored. I look to see if the second and third run of A are roughly equal, and the same for B. If so, then the JVM has probably settled into a steady state for each method, and the times are meaningful. If not, it's probably necessary to increase the number of repetitions.
I followed your recommendation, and got interesting results, -- now the access by method invocation is consistently faster than direct access by field, no matter which test is run first. The difference is still just a few hundreds of milliseconds, and considering the resolution of the System.currentTimeMillis() method (16 ms on Windows?), it's probably still not meaningful. Here is the new code:

BTW, why is it the that new lines are not preserved when I post code? I know that it works for majority of the posters, but it never does for me. I use JBuilder for code, is there some option that loses the new lines when I copy from there and paste here?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Eugene Kononov:
BTW, why is it the that new lines are not preserved when I post code? I know that it works for majority of the posters, but it never does for me. I use JBuilder for code, is there some option that loses the new lines when I copy from there and paste here?


As far as I can tell it's an UBB bug. The only workaround I know is to put spaces into the empty lines.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic