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.
(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.