Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations wOOdy-Soft on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Increasing Java's Speed
- Thread starter k4ghg
- Start date
sedj
Programmer
- Aug 6, 2002
- 5,610
CPU ? RAM ?
You can increase Java's JVM memory via :
"java -Xm256m -Xmx256m myClass"
where 256 is your RAM in Mb to allocate.
What exactly are you doing in the application - where do you feel the slowness is occuring ?
--------------------------------------------------
Free Database Connection Pooling Software
You can increase Java's JVM memory via :
"java -Xm256m -Xmx256m myClass"
where 256 is your RAM in Mb to allocate.
What exactly are you doing in the application - where do you feel the slowness is occuring ?
--------------------------------------------------
Free Database Connection Pooling Software
- Thread starter
- #3
I am using several data source (climatic information - rainfall, temperature, solar radiation, soil data irrigation efficiency), to calculate monthly irrigation requirements for an unknow (i.e., varies) number of wells. I currently have a Visual Basic program that works real fast.
My Java program reads in data and calculates (using basic math and power funtions). I use Arralists for the unknow numbre of wells and each well has about 9 variables.
I have only finished the basic calculations and the output to screen is very slow. By the way the program consists of over 6,000 lines.
Thanks...Ronnie
My Java program reads in data and calculates (using basic math and power funtions). I use Arralists for the unknow numbre of wells and each well has about 9 variables.
I have only finished the basic calculations and the output to screen is very slow. By the way the program consists of over 6,000 lines.
Thanks...Ronnie
(this homepage shows Java array is faster than Java ArrayList)
In order to increase Java Application performance, some good Java characteristics have to be sacrificed.
Reuse object, decrease the number of initialize object.
Decrease the number of method call.
Do not use recurson
use calculated variable in for loop
for (int i=0; i<myString.length(); i++)
should be replaced by
int len = myString.length();
for (int i=0; i<len; i++)
In order to increase Java Application performance, some good Java characteristics have to be sacrificed.
Reuse object, decrease the number of initialize object.
Decrease the number of method call.
Do not use recurson
use calculated variable in for loop
for (int i=0; i<myString.length(); i++)
should be replaced by
int len = myString.length();
for (int i=0; i<len; i++)
sedj
Programmer
- Aug 6, 2002
- 5,610
And why would that be Dian ?
--------------------------------------------------
Free Database Connection Pooling Software
--------------------------------------------------
Free Database Connection Pooling Software
I'm sure you know the answer 
Anyway, Java is an interpreted Language, it implies running a procces (JVM) that understand the bytecodes that our program is translated (.class) into by the compiler.
This allows Java to be multiplatform and so on, but decreases its performance against compiled languages where the code is directly translated into an executable file without any more process involved. Furthermore, as long as the compilers used to be associated with a single OS and platform, they use to be highly optimized to increase performance on that platform.
Cheers.
Dian
Anyway, Java is an interpreted Language, it implies running a procces (JVM) that understand the bytecodes that our program is translated (.class) into by the compiler.
This allows Java to be multiplatform and so on, but decreases its performance against compiled languages where the code is directly translated into an executable file without any more process involved. Furthermore, as long as the compilers used to be associated with a single OS and platform, they use to be highly optimized to increase performance on that platform.
Cheers.
Dian
sedj
Programmer
- Aug 6, 2002
- 5,610
I keep quoting this resource as saying that "in basic primitive data type alorithms, Java is *almost* comparable to native C", but I can never find that benchmark test on the web again !
I think with todays processor speeds, Java is *basically* as quick as C though. Obviously it will never be *as quick* due to the reasons Dian mentioned earlier - but its negligable.
Anyone fancy doing a benchmark ?![[wink]](/data/assets/smilies/wink.gif "[wink] [wink]")
--------------------------------------------------
Free Database Connection Pooling Software
I think with todays processor speeds, Java is *basically* as quick as C though. Obviously it will never be *as quick* due to the reasons Dian mentioned earlier - but its negligable.
Anyone fancy doing a benchmark ?
--------------------------------------------------
Free Database Connection Pooling Software
- Thread starter
- #9
I'd like to see those benchmarks too. I've done some C++ work on number generators. Such type of process consist basically on a bunch of simple operations on simple data types.
Each process used to take about one or two days, and I still think that if I had done it with Java, I'd still be waiting for them.
But I agree in one point: with today processors and for normal applications, a Java program is kick enough (not as kick a C though). I think the difference comes when performance is not an optional issue but the key one. That's where Java losses its advantage.
Cheers.
Dian
Each process used to take about one or two days, and I still think that if I had done it with Java, I'd still be waiting for them.
But I agree in one point: with today processors and for normal applications, a Java program is kick enough (not as kick a C though). I think the difference comes when performance is not an optional issue but the key one. That's where Java losses its advantage.
Cheers.
Dian
stefanwagner
Programmer
The point is from bottom up wrong.
Because of HotSpot and JIT-compiling java may be FASTER than statically compiled c-Programs (and is - if you use it right).
But of course it needs some experience, to handle performance right.
And the central-point isn't 'reuse Objects, avoid method-calls, use a instead of b'.
a) start by choosing the right data-structure.
b) use the appropriate Collection. A collection which is fast in sorting might be slow in inserting/ deletion and vice versa.
c) write efficient algorithms
d) make use of multi-threading when appropriate
e) measure with a profiler.
f) perhaps you may start now with low-level performance-optimization which leads to more ugly code.
btw: be sure to use at least a 1.4.2-java.
A benchmark (with most problems, every benchmark has) might be found here:
The graphics seems to show, that java is slow, but you can find out, that this is only coming from the trigonometric calculations. In every other field java was fastest or close to fastest.
Mentioning the number of lines of code is of zero information. The optimizers often use a loop-unrolling which leads to much more code, and performance(=speed)-benefits.
So optimisation for speed or size is normally exclusive - you may only have one of both.
seeking a job as java-programmer in Berlin:
Because of HotSpot and JIT-compiling java may be FASTER than statically compiled c-Programs (and is - if you use it right).
But of course it needs some experience, to handle performance right.
And the central-point isn't 'reuse Objects, avoid method-calls, use a instead of b'.
a) start by choosing the right data-structure.
b) use the appropriate Collection. A collection which is fast in sorting might be slow in inserting/ deletion and vice versa.
c) write efficient algorithms
d) make use of multi-threading when appropriate
e) measure with a profiler.
f) perhaps you may start now with low-level performance-optimization which leads to more ugly code.
btw: be sure to use at least a 1.4.2-java.
A benchmark (with most problems, every benchmark has) might be found here:
The graphics seems to show, that java is slow, but you can find out, that this is only coming from the trigonometric calculations. In every other field java was fastest or close to fastest.
If you redirect the output to a file, it might speed up significantly, if there is a lot of output (factor 100 will not be unusual).
Mentioning the number of lines of code is of zero information. The optimizers often use a loop-unrolling which leads to much more code, and performance(=speed)-benefits.
So optimisation for speed or size is normally exclusive - you may only have one of both.
seeking a job as java-programmer in Berlin:
Aahh, you Java fanatics
You won't make me think Java is the fastest. So it's multiplatform, object-oriented, easy to code and read, reasonably easy to maintain, and appart from that it's the fastest!
Come on. You're talking about hyper-optimized Java programming with the best JIT compilators and so on. If you use all that effort to optimize code and compilator for any native language like C, it will be faster for sure.
I agree that Java has improved a lot on performance, and that's more than enough for most applications, but we should remember what's Java designed for, and that's not speed.
Cheers.
Dian
You won't make me think Java is the fastest. So it's multiplatform, object-oriented, easy to code and read, reasonably easy to maintain, and appart from that it's the fastest!
Come on. You're talking about hyper-optimized Java programming with the best JIT compilators and so on. If you use all that effort to optimize code and compilator for any native language like C, it will be faster for sure.
I agree that Java has improved a lot on performance, and that's more than enough for most applications, but we should remember what's Java designed for, and that's not speed.
Cheers.
Dian
stefanwagner
Programmer
Well - as long as you 'THINK' whether java is fast you fail.
Test and prove and you may stop believing, because that is, what you do, when talking about 'thinking'.
Thinking is something else.
And I'm not talking of hyperoptimization or derivate compiler switches - just about avoiding some beginners-faults.
seeking a job as java-programmer in Berlin:
Test and prove and you may stop believing, because that is, what you do, when talking about 'thinking'.
Thinking is something else.
And I'm not talking of hyperoptimization or derivate compiler switches - just about avoiding some beginners-faults.
seeking a job as java-programmer in Berlin:
stefanwagner
Programmer
I would like to know, if the redirection to a file worked as expected...
seeking a job as java-programmer in Berlin:
seeking a job as java-programmer in Berlin:
Dian has a valid point there.
If you apply that same energy (using profiler, examining the C/C++ library and carefully using the ones that give you the best performance, and such) on your C/C++ program, you are bound to get a much much faster C++ programs. Furthermore, with C/C++, you can bypass your operating system and communicate directly with your hardware.(That's if you want to go that far to get your speed, which is what many games programmers used to do prior to DirectX).
I have no grudges against any particular language. While Java has its own merits, speed is definitely not Java's strength. I am not saying that Java is slow (In fact, Java's performance has been pretty good for most applications). It's just that Java is not quite as fast as C++. I tend not to believe the results of those benchmarks. I have seen many benchmarks saying that Java is faster than C++, or C++ is faster than Java, or Java is as fast as C++. All of them lead to non-conclusive result.
You need to know that Java is created in C/C++. Anything that Java can do, C/C++ can do just as well or even better. So the "Java is faster than C++" argument is a complete bull, especially since Java is born out of C/C++. Java is created with portability in mind. So if you want to pit Java against C++, you should use the "Java is more portable" argument.
If you apply that same energy (using profiler, examining the C/C++ library and carefully using the ones that give you the best performance, and such) on your C/C++ program, you are bound to get a much much faster C++ programs. Furthermore, with C/C++, you can bypass your operating system and communicate directly with your hardware.(That's if you want to go that far to get your speed, which is what many games programmers used to do prior to DirectX).
I have no grudges against any particular language. While Java has its own merits, speed is definitely not Java's strength. I am not saying that Java is slow (In fact, Java's performance has been pretty good for most applications). It's just that Java is not quite as fast as C++. I tend not to believe the results of those benchmarks. I have seen many benchmarks saying that Java is faster than C++, or C++ is faster than Java, or Java is as fast as C++. All of them lead to non-conclusive result.
You need to know that Java is created in C/C++. Anything that Java can do, C/C++ can do just as well or even better. So the "Java is faster than C++" argument is a complete bull, especially since Java is born out of C/C++. Java is created with portability in mind. So if you want to pit Java against C++, you should use the "Java is more portable" argument.
stefanwagner
Programmer
No - that is humbug.
A ship is build from steel - so steel needs to swim much faster? (downward - yes.)
You could create binary code by tipping it into a hex-editor, by generating it with tools, written in assembler or in a scripting language.
You wouldn't do it, but you could generate the same bytecode with very different tools.
That has no causal influence on the speed of the result.
You could write a c++-compiler in java - what does it proof? Nothing.
------------
I'm not applying some extra energy in performance questions, and didn't talk about investigating the inner facts of collections.
But if you use collections in a wrong way, you will loose performance as you will with the c++ STL when you don't know the fundamental usage of collections.
And I only mentioned a profiler, for those, who need more performance than they have reached, and to show, how late in the develepment process I would use it.
You claim
Today, you can only measure it by the amount of badly informed people who believe it's slow.
You may download the benchmark source, compile it on your system, and see.
And see, that there isn't any mysterious energy spent, to give java an advantage.
If your results differ, tell us.
If you find a reason to complain about the benchmark, tell us.
If you find a different benchmark, which shows the benefits of c++ over java, tell us.
Or you keep on spreading your prejustices...
seeking a job as java-programmer in Berlin:
A ship is build from steel - so steel needs to swim much faster? (downward - yes.)
You could create binary code by tipping it into a hex-editor, by generating it with tools, written in assembler or in a scripting language.
You wouldn't do it, but you could generate the same bytecode with very different tools.
That has no causal influence on the speed of the result.
You could write a c++-compiler in java - what does it proof? Nothing.
------------
I'm not applying some extra energy in performance questions, and didn't talk about investigating the inner facts of collections.
But if you use collections in a wrong way, you will loose performance as you will with the c++ STL when you don't know the fundamental usage of collections.
And I only mentioned a profiler, for those, who need more performance than they have reached, and to show, how late in the develepment process I would use it.
You claim
and you have no proof. It was true in former times, and you could measure it.
Today, you can only measure it by the amount of badly informed people who believe it's slow.
You may download the benchmark source, compile it on your system, and see.
And see, that there isn't any mysterious energy spent, to give java an advantage.
If your results differ, tell us.
If you find a reason to complain about the benchmark, tell us.
If you find a different benchmark, which shows the benefits of c++ over java, tell us.
Or you keep on spreading your prejustices...
seeking a job as java-programmer in Berlin:
To me Java is like an automatic gearbox, while C/C++ is like a manual gear box. A engine (CPU) using manual gearbox get slightly (only slightly) better performance than automatic. Unless you are drive on a speed track or for your own driving fun, you would just go for automatic, right. If you are just want a car that can go for 100 mpg, you wouldn't bother to drive manual, will you.
By the way, here is the prove that Java could be as fast as C++
By the way, here is the prove that Java could be as fast as C++
stefanwagner said:
Go ahead and try it. You may as well try writing an operating system or hardware devices in Java. I'd like to see how you can generate a native executable file in pure Java (which may be possible - who knows?), or even work directly with hardware.
Come on now. If Java is really that good (even in term of performance and speed), the whole software industry would have switched to Java by now. After all, it is portable, convenient, easy (eg. no worry about garbage collection), and now even FASTER than C/C++ ?!?! Operating systems (UNIX, Linux, etc.), hardware devices, etc. would no doubt be ported to Java by now.
Java is a high-level language (even higher level than C/C++). It saves you development time, and provides all those neat features for your convenience. However, it is not meant for low-level work. You cannot write hardware devices in Java. Let alone writing an operating system. I even doubt that you can use Java to write C/C++ compiler.
Try debugging your Java and C/C++ programs. Java programs contain a lot more machine-level instructions than the equivalent C/C++ programs. More instructions means longer execution time.stefanwagner said:
One instruction in assembly language contains one machine instruction. Now, one instruction in C/C++ contains an average of two machine-level instructions (Still trying to find that whitepaper). Now, how closer to the metal can you get with Java?.
It's not prejudice. While Java has its merits, I feel that much of the facts about Java is somewhat overhyped. Many Java proponents try to make Java looks like one-size-fit-all solution. Now that is naive. No programming language claims to have one-size-fit-all solution for all your programming problems. Despite the power in C/C++, C/C++ is not for novice to use. Despite the ease of programming and speed of development in VB, VB proponents still have the decency to admit VB's limitation when it comes to size and speed of execution. Now, how naive can you get when a Java advocate claims that Java is smaller (due to the fact that many parts of the program is already in the JVM), more portable, easier, as powerful, and NOW even FASTER than C/C++?!?!stefanwagner said:
Now, this Java vs C++ argument is pointless. It's even off this thread's topic.
For those who interested, here is another reference comparing performance of Java vs C++.
Prehaps Java is not low level enough to write Operation System, but there is project going on at Sun "Project Looking Glass" writing a Linux 3D Desktop using Java, which is very very cool.
I'm not trying to sell Java here, or saying Java is better than C/C++. It just that I think some of you may be interested.
Prehaps Java is not low level enough to write Operation System, but there is project going on at Sun "Project Looking Glass" writing a Linux 3D Desktop using Java, which is very very cool.
I'm not trying to sell Java here, or saying Java is better than C/C++. It just that I think some of you may be interested.
- Status