Reputation: 1354
I faced a very frustrating issue. I used an IDE to develop my application. I was monitoring performance through the execution times in IDE but unfortunately when I exported my classes to Jar files, it ran 7x slower on command line. I checked my JVM and made sure the same JVMs are linked to both executions. Allocated more heap memory to the commandline.
Later, I used a process performance monitoring tool and ran both applications (on CMD & on IDE) simultaneously. I noticed that both processes are identical on everything but for CPU power. The process running on IDE takes around 19%-23% of CPU usage while this on CMD took about 6%-11% CPU usage. This may explain why the run on IDE takes less time.
In order to make the application clear, below is the piece of code that taking most of the time
for (Call call: calls {
CallXCD callXCD = call.getCallXCD();
if(callXCD.isOnNet()){
System.out.println("OnNet");
}
else if (callXCD.isXNet()){
System.out.println("XNet");
}
else if (callXCD.isOthers()){
System.out.println("Others");
}
else if (callXCD.isIntra()){
System.out.println("Intra");
}
else {
System.out.println("Not Known");
}
}
CallXCD is an object containing several string variables and several methods like isOnNet and isXNet. These methods apply the compareTo() method on the strings of the object and return true or false according to this comparison.
I profiled this piece of code by printing the time each iteration take. In the IDE each iteration took about 0.007 milli second while in command line running the jar file, it took about 0.2 milli second. Because my code takes around 4 million iteration on this, the negative impact on performance is very significant
Why does this happen?. Is there any way to allocate more processing power to JVM like memory arguments.
Upvotes: 1
Views: 634
Reputation: 27450
Not an answer per se but I would like share my own experience.
Under Java 21, the same JMH benchmark runs significantly faster using IntelliJ IDEA than invoking Java. CPU Power consumption seems to be similar. I have explored several tracks which lead nowhere.
Upvotes: 0
Reputation: 1500485
(After a conversation in comments.)
It seems this is down to a difference in how console output is handled in your command line and in your IDE. These can behave very significantly differently in terms of auto-scrolling, size of buffer etc.
Generally, when benchmarking code it's good to isolate the code you're actually interested in away from any diagnostic output which can interfere with the results. If you absolutely have to include diagnostic output, writing it to a file (possibly on a ram disk) can help to reduce the differences between console implementations.
Upvotes: 4
Reputation: 14159
I have seen such effects when the IDE (eclipse) used a newer Java version than is used when starting from the command line. Also, it could be that when running from within eclipse you are using the server VM and on the command line the client JVM is used. This can either be set in the run configuration or in the wirkspace JVM settings ("Default VM arguments" when you click on "Edit JRE" in the "Installed JREs" preference page).
So, first make sure the same arguments are used. Add the arguments that are used when starting from within eclipse to your command line.
Upvotes: 0
Reputation: 14164
Maybe your IDE has different JVM options, for running your process? Larger heap size (-Xmx) could reduce garbage collection costs. If your application is memory-intensive & choking on an insufficent heap size, this could easily be the problem.
The IDE typically also pipes your process's standard input/ output. I don't know if that would be more efficient than standard output to console, but if you're printing/logging a lot it might be a factor to consider.
As Jon Skeet says, there's a big apparent difference between the I/O traces on left & right.
The third main thing an IDE does, in Debug mode, is attach to your process as a debugger. But this normally makes the process slower, not faster.
Summary: best check your IDE's JVM options & launch configuration. Maybe it's run with different parameters, in a different working directory, or with too small a heap size.
Upvotes: 0