aspose file tools*
The moose likes Performance and the fly likes forcing classes to be loaded in advance to improve performance Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Performance
Bookmark "forcing classes to be loaded in advance to improve performance" Watch "forcing classes to be loaded in advance to improve performance" New topic
Author

forcing classes to be loaded in advance to improve performance

Ron Price
Greenhorn

Joined: Apr 08, 2005
Posts: 13
Hello,

I know that for the most part the JVM loads classes in a lazy manner (on-demand, or as needed). I have an application where I don't want the user to have to wait for any class to be loaded and I'm thinking about "priming" the JVM by forcing all classes to loaded before they are needed. I envision this as either a component of my application or as a separate program all together. The "priming" would be done by explicitly loading every relevant class before they are needed so that class loading doesn't give the user any perceived performance hit.

What do you think?

I'm wondering if I'll break anything? (in terms of security, best practices and like)



Thanks,

-Ron


Ron Price<br />Quantica Systems<br /><a href="http://www.quanticasystems.com/" target="_blank" rel="nofollow">http://www.quanticasystems.com/</a>
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41474
    
  51
Before doing any optimizations, you should be certain that what you're about to do actually improves (perceived) performance. Is that the case, or are you merely acting on a hunch?

I'm fairly convinced that the impact of this would not be noticeable.


Ping & DNS - my free Android networking tools app
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Well, I'm less convinced than Ulf that this will not be noticeable, but I agree that you should try to measure this beforehand. For some applications, like, say, a video game, it may indeed be desirable to force the user to wait longer at startup, to enhance the experience once the game actually begins.

If you observe that your program seems slower at startup than after it's been running a bit, there are two likely reasons for this: (1) class loading, and (2) Just-In-Time compilation and optimizations. Forcing all your classes to load in advance will help with the first, but not the second. Additionally, creating a list of all the classes used by your program is a bit of a pain to maintain. You may easily change the code but forget to change the list of classes.

An alternative would be to write some methods to exercise some of the key parts of your program by running them repeatedly for a bit at startup. This allows the JIT compiler to try to optimize whatever parts of code are taking the most time. And it incidentally also loads the classes it needs. Depending on how much time you want to spend warming up the program, you may get substantial improvements over the performance you get with no warm-up. However there will be diminishing returns - past a certain point, you just can't get it to go any faster. So again, it will be very useful to measure how big the difference in performance actually is, and compare it to the difference you get with no warmup (or with a shorter warmup), to evaluate how to spend your time.
[ August 23, 2007: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
Maneesh Godbole
Saloon Keeper

Joined: Jul 26, 2007
Posts: 10245
    
    8

Whoa! I am a bit confused here. When you say forcibly loading the classes, I presume, you are going to do something like Class.forName(....)

Scenario 1: Normal Case
main() is invoked and the JVM figures out the classes and dependencies if any and loads them accordingly

Scenario 2: Optimized case
There is a bunch of Class.forNames as the very first instruction set in main and then the code will proceed as Scenario 1.

Isnt the only difference the sequence between these two? Instead of loading the classes as and when required, all of them were loaded initially? Doesnt the time required to load these classes remain the same?

Wheres the advantage then? Unless of course you are talking about something totally different and I have misunderstood.


[How to ask questions] [Donate a pint, save a life!] [Onff-turn it on!]
Ron Price
Greenhorn

Joined: Apr 08, 2005
Posts: 13
Thanks for getting back to me on this.

Jim, thanks for stating what I forgot to state which was the JIT time.

Ulf, I'm not just acting on a hunch. The idea came to me because when I run my app from eclipse the first time it launches 7 seconds and the second time it launches in 2 seconds. Now, I realize what I'm seeing may not be all due to class loading and JIT time, but it got me thinking. Then at JavaOne I had an in depth chat with the Sun JVM developers about java performance and asked them some similar Questions. So, Ulf it is probably slightly more than a hunch, I wish I had more details and data to back up the idea.

So, I'm in a situation where potentially 1ms of time could cost the user 1mil dollars. Every little bit of speed helps.

Also, it seems to me that if you can "prime" the JVM jsut right for your app then you could make your java app faster than a C/C++ app under certain situations. I'm very interested in this.

Thanks to everyone for replying!!!


Ron Price
Greenhorn

Joined: Apr 08, 2005
Posts: 13
Originally posted by Maneesh Godbole:

Scenario 1: Normal Case
main() is invoked and the JVM figures out the classes and dependencies if any and loads them accordingly
Scenario 2: Optimized case
There is a bunch of Class.forNames as the very first instruction set in main and then the code will proceed as Scenario 1.
Isnt the only difference the sequence between these two? Instead of loading the classes as and when required, all of them were loaded initially? Doesnt the time required to load these classes remain the same?

Wheres the advantage then? Unless of course you are talking about something totally different and I have misunderstood.


Here is an example of where I feel "priming" the JVM could help.

Let's say we have a trading system/engine. It constantly hunts for profitable opportunities. Now let's say that we we have loaded and run the JIT on all of our classes except for class Z. Let's also say that class Z is needed to execute a trade which makes us money. Now, our trading system just found trading opportunity, but in order to execute the trade the JVM must load class Z and JIT must run on class Z. This could cost us our opportunity to make money.

Note, what Jim mentions above about class loading and running the JIT is what I'm trying to get at.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Well, sounds like there could indeed be a good reason to do this, and it would be worthwhile to make more measurements to see how much effect it has. Note that when you observe the launch time from Eclipse, you could be observing several other unrelated effects, as Eclipse may be spending time compiling your class, or running/loading/optimizing it's own code, just to monitor and display what your code is doing. And anyway, what you're seeing there is the startup time, which in your scenario you don't really care about. (You can warm up your trading engine before the market opens, for example, or while other instances of the engine are running on other machines.)

I would try to write some good performance tests to measure response times under realistic conditions - or as close to realistic as you can get. Ideally, use a test environment which is a close copy of the production environment, including whatever enterprise server or framework(s) you plan to employ in production. For an application such as you describe, this will be useful for a lot more than just testing this particular optimization idea you have - you want some good, reliable numbers on any performance problems that may come up. Once you've got that, then try writing a simple warmUp() or preloadAllClasses() method to run as part of your engine's initialization, and see if it helps. Like most all performance optimizations, it's very easy to spend time and add complexity on things which don't really help you in the end (and may even harm you), so it's valuable to be able to measure what effects your changes are having.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41474
    
  51
Interesting indeed. But then you should probably also look into the effects of garbage collection, which may happen at some very inopportune moments, and delay everything in the order of seconds.

There's also a (within limits) real-time JVM from Sun, which I believe used to be a commercial offering, but whose technology is now folded back into the regular JVM. That would presumably have better -or at least more predictable- GC characteristics.
Ron Price
Greenhorn

Joined: Apr 08, 2005
Posts: 13
Originally posted by Jim Yingst:


I would try to write some good performance tests to measure response times under realistic conditions - or as close to realistic as you can get. Ideally, use a test environment which is a close copy of the production environment, including whatever enterprise server or framework(s) you plan to employ in production. For an application such as you describe, this will be useful for a lot more than just testing this particular optimization idea you have - you want some good, reliable numbers on any performance problems that may come up. Once you've got that, then try writing a simple warmUp() or preloadAllClasses() method to run as part of your engine's initialization, and see if it helps. Like most all performance optimizations, it's very easy to spend time and add complexity on things which don't really help you in the end (and may even harm you), so it's valuable to be able to measure what effects your changes are having.


Thanks for helping conceptualize this! The warmUp() method would be exactly what I had in mind.

Thanks for all the great info.

-Ron
Ron Price
Greenhorn

Joined: Apr 08, 2005
Posts: 13
Originally posted by Ulf Dittmer:
Interesting indeed. But then you should probably also look into the effects of garbage collection, which may happen at some very inopportune moments, and delay everything in the order of seconds.

There's also a (within limits) real-time JVM from Sun, which I believe used to be a commercial offering, but whose technology is now folded back into the regular JVM. That would presumably have better -or at least more predictable- GC characteristics.


Ha! Earlier today I started another post with GC as the topic.
Yes, GC is concerning. I don't think real-time is freely available.
Hmmm, any info on real-time being part of the regular JVM?

So, I realize C/C++ still has its place and I may right some of the engine using JNI, although I would really like it to be all java.

Thanks for all the info.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
[Ulf]: But then you should probably also look into the effects of garbage collection

Excellent point. This could very well be a much bigger issue - at least, more of a recurring issue, once the engine has been running for a few minutes. It will probably be worthwhile to look into some of the many articles and whiepapers on tuning garbage collection, such as this one. (Similar papers exist for other JVM versions; find the appropriate one.) Finding the right combination of JVM command-line parameters could well be much more important than adding a warmUp() method.
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41474
    
  51
Originally posted by Ron Price:
I don't think real-time is freely available.
Hmmm, any info on real-time being part of the regular JVM?


Seems like I imagined that. The RTS home page is here, and it contains no reference to the technology being folded back into the mainstream JVM. Currently, it's available for Solaris only anyway.

Some further links about RTS and realtime GC are in this article.
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
That real-time Java stuff is very interesting. Expensive, though, I guess?


Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
Originally posted by Ron Price:
I'm in a situation where potentially 1ms of time could cost the user 1mil dollars


... and yet you don't want to pay for a proper real-time system? Ever heard of the term "false economy"?!
Ron Price
Greenhorn

Joined: Apr 08, 2005
Posts: 13
Originally posted by Peter Chase:


... and yet you don't want to pay for a proper real-time system? Ever heard of the term "false economy"?!


I'm not sure how expensive real time is. I did look, it appeared I would have to contact Sun for the price; I'm not that interested yet.

Peter, it isn't that I don't want to pay for a proper real time system. For now I'm investigating all my options and confirming concerns about overhead due to class loading, JIT and GC. If my group comes to the conclusion that real-time is the best choice then we will obtain it. In real-time you have three types of threads: normal, slightly memory limited and very memory limited. In order to get real-time behavior you have to create a real-time thread that cannot have any dynamic memory allocation and you get complications similar to C/C++. This is a concern for me. At that point maybe I should just use C/C++. I would really like to use java, but I'm not sure real-time is the solution for my problem. Also, I need to decide just how crucial time is for the trading system. It may be that a java implementation of the trading system is faster than a C/C++ due to design, performance tricks and the distributed computing functionality. Also, we are not planning on having the trading system complete all trades autonomously, if at all. Allowing the trading system to be run by AI is how Goldman Sachs and others lost billions recently (Side Note: not sure who convinced the financial giants that AI is a good idea when billions are involved, AI is not ready for this yet; no way to teach the system to truly learn). So, there are more concerns than price alone, I want the right technology for my problem.

Thanks,
Ron Price
Greenhorn

Joined: Apr 08, 2005
Posts: 13
I wanted add one more bit here about java real-time. I chatted with
the real-time developers at javaOne and real-time is very cool and it has its place. The key feature, from my perspective, is that methodA() will alway take the same amount of time with java real-time if it is written using the magic real-time threads. The point of my comment is that the name of real-time may be a bit misleading. What it really insures is that methodA() will run in the same fixed amount of time every time (no GC interruption or anything else).
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18541
    
    8

Personally, I still feel that there's premature optimization going on here. "Every little bit of speed helps" isn't a service level that can be met. But on the other hand you said "I need to decide just how crucial time is for the trading system" which is more realistic.

You aren't going to be able to assess the impact of class loading or garbage collection or what have you without implementing something that can be assessed. At the moment you have only speculation. I think writing and testing something should be your next step.
Ron Price
Greenhorn

Joined: Apr 08, 2005
Posts: 13
Thanks for all of your comments.


I just want to ask two more questions regarding most java applications:

How many people think that the time taken by the JVM for class loading, JIT processing and the garbage collector running would be significant?

How many people think that running the garbage collector is significant, but class loading and JIT are not significant?

I really think that for most applications java is more than fast enough.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Those are very vague questions, and I'm not sure what "most applications" have to do with your application. Let's at least limit it to server-based applications that start up and then run for a long time. I'll say that for most applications, class loading and JIT processing are not significant problems. GC typically isn't either, but it's more likely to be significant than the others are. Whether any of that is true for your application remains to be seen.

[Ron]: I really think that for most applications java is more than fast enough.

Sure, if that weren't true for a sizable number of applications at least, most of us probably wouldn't be programming in Java.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: forcing classes to be loaded in advance to improve performance