Is there any way to detect what the cpu is doing while your program is running? My thought is that I could run a 'stress test' on the computer the program is running on. Depending on the results, it would set program options differently at runtime. I could turn off music or load lower quality images, etc.
Is there any way to detect what the cpu is doing while your program is running?
The standard way to answer this question in a systematic manner, as well as to identify the bottlenecks and to improve the performance of your app is to use a profiler. The are many different ones on the market, such as OptimizeIt, JProbe, and others. As you profile the app, you get a report of how much time is spent in each method (or even on each line) of your code. The practice shows the 80-20 rule: 20% of the code runs 80% of the time. Once the 20% is identtified, it can be optimized to improve the performance. This discussion clearly belongs to the "performance" forum here.
Joined: Sep 10, 2002
I haven't gotten my real question across. I'm not trying to profile the performance after its run. I want to adjust the performance WHILE its running. If I were making a game, I would want it to be the best experience I could. On a super fast computer, having all the graphics and sounds turned on and the AI would be fine. On an older computer, maybe the AI routine needs to be turned down a bit and the graphics adjusted by using smaller textures.
You can optimize a program, but until its running on the actual machine, you won't know how its going to perform. I want to check the CPU load while my app is running and then adjust how the program is running. This isn't really a performance issue, so much as what a specific computer can handle one.
On another forum, some one mentioned my only solution was JNI. I had hoped this wasn't the case, as it will lose its platform independence.
You can't easily tell what they CPU is doing, but you can tell what your program is doing. Some critical method might keep track of max, min and average elapsed times for the last "n" calls and adjust its internal algorithms, perhaps switch between strategies.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Sep 10, 2002
Thats not a bad idea. I know trying to 'profile' code that way is usually frowned up, but maybe for doing what I'm aiming at, it might be ok. The only difficulty might be in trying to easily figure out where the acceptable range is.
Thanks for the input!
Regards, Aaron R>
Joined: Jan 29, 2003
Hmmm, frowned upon? We do that kind of thing in production and report when anything goes over 3 seconds. It's a valuable indicator of trouble. We often know of slow-downs or failures before the users call us to complain.
I built something that keeps stats on any method for a configurable number of intervals of a configurable length, say the last 60 1-minute intervals for an hour's worth of data. Each interval tracks number of calls, max, min and average time. The code in the method is simple: