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 strongm 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

Status
Not open for further replies.

k4ghg

Technical User
Dec 25, 2001
191
US
Hi - I am developing an application and it seems to load and run very slooooooooow. In general is there a good tuturial or does any one have specific tips on increasing Java's speed? Thanks
 
Hy Zech,

Nobody was talking about hardwaredrivers, but it's nice to see, how you offtake.

And I don't know what the principal problem should be to write a c++ - compiler in java.
Allthough I allways used a linker to make native executables in c++, why not writing a linker in java? You know the difference between linker and compiler?

More instructions means longer execution time.
That sounds plausible in the first second.
But I argued on that before - didn't you read it?
Try to optimize your c++ - programs for size AND speed.

And I didn't claim java to be a 'one-fits-all' solution.

I only mentioned the speed-improvements during the last years working with java.
And I don't want to pit against c++ - I just want to see the facts.

seeking a job as java-programmer in Berlin:
 
I wrote the data to a file and work worked pretty good. I think my problem relates to the report generator that I am using. Does anyone have any recommendations for a good/fast programable report generator or a preint preview library?

Thanks...
 
@ k4ghg,
Glad to see that you've solved your problem.


@stefan,
I do not wish to carry this silly arguments further but I do recommend that you do a further research into compiler and linker programming before making your case.

stefanwagner said:
You know the difference between linker and compiler?
I came from a C background and I have been using cc and makefile since before all those fancy visual c++ came. So, I do know the difference between a compiler and a linker. A compiler creates an object (.obj) file from your source codes and a linker links all those different object files (.obj) into one executable module. It would be very interesting to see how you are going to map all those memory addresses without the use of pointers.

stefanwagner said:
Quote:
>>More instructions means longer execution time.
That sounds plausible in the first second.
But I argued on that before - didn't you read it?
Try to optimize your c++ - programs for size AND speed.
I was talking about machine-level instructions and not some high-level language instructions (which consists of several machine level instructions). It doesn't matter what language you use but your machine will execute the machine instructions one by one. So the longer the machine-level instruction, the longer it will take to execute your program. High-level languages usually have convenient features and powerful commands. However, these features and commands are often expensive because they often means more instructions at the machine-level.


I won't carry this argument further but, for a side note, I do always optimize my codes. I work in a game industry and, in a game business, we are pushing the hardware to the limits with all those fancy 3D graphics and multiple AI running in the background. Gamers want the best graphics, the best actions (meaning:speed), the best sound, the smartest AI, powerful network play (meaning: no or less lag), while enabling them to do something else with their computers. All those are very taxing to the machine, especially many hardware is not designed for gameplay. So, for those of us in the game business, we often have to 'hack' into the hardware with our codes, squeezing every last bit of performance to get our games running. So don't give me that "Try to optimize your c++ - programs for size AND speed" argument. Optimization is what I do for a living.

 
OK - I'm really a greenhorn in questions of machine-level-instructions.

You sayed
Java programs contain a lot more machine-level instructions than the equivalent C/C++ programs. More instructions means longer execution time.

You would say that
Code:
++a;
leads to more machine-level-instructions for a java-program than for a c++ program?
Isn't that depending on the java-compiler and jvm vs. c++ compiler?
Won't it depend on the version of java(1.3, 1.4), the producer (sun, ibm, ...) and the os-implementation (linux/ mac/ win) and the c++ stuff as well whether Borland or MS and Dos or Unix and version x.y?

And if it's not a constant, only depending on the language: Java or C++ - how can you be sure that c++ has allways fewer machine-level instructions?

After clearifying this, the question is, how can ANYTHING be done without pointers in java? Isn't it impossible?

And what do Hotspot- and JIT-Compiler do?
If they throw away a lot of unused machine-level-instructions?

I would never tell you, that you could adress the graphic-ram or other hardware faster in java than in c++.

But being fast in this cases doesn't mean being fast in general.

seeking a job as java-programmer in Berlin:
 
k4ghg,

Assuming your data size is not taking about thousands or millions, if you output your data in XML form, you can then easily transform the data into any other output format using XSLT.

 
You can write almost a full OS in Java.
There is an OS called JNode that is based on GNU classpath, an open source implementation of Java. They modified classpath and replaced the native code with Java code. It a little more than 99 % Java based!

Check for more info.

Java can be faster or as fast as C becourse the JIT compiler generate native code. It uses runtime information to optimise the code, it also optimise the code for your CPU (P3 or P4, SSE 2, cache size).
 
Carmello :

I beg to differ, but to say "write an OS in Java, and not include native code" is like saying "I've got a car without an engine".

Lets not forget that Java can ONLY interface with the OS via native compiled machine code (usually via C/C++ libraries).

As for the speed thing, I'm a fairly die-hard Java lover, but I recently did some basic IO/Socket stuff as a comparison.

1) Copy a file.
2) A simple TCP/IP socket server/client.

One implemented through "pure" Java.
One implemented in C, and then called via Java (ie what Java does in the backgound).

To copy a 20 Mb file in Java cost 8 seconds on a 300MHz linux box. To do the same in C cost 90 milliseconds.

The socket comparison was the same kind of speed difference.

Enough said.

--------------------------------------------------
Free Database Connection Pooling Software
 
Good tips and tricks for optimizing the JAVA performance can be found in Jack Shirazi's book "JAVA Performance Tuning" from O'Reilly & Associates (ISBN: 0596003773).

Good luck,

Tom
 
Slow Java programs under modern JVMs are almost always caused by poor programming of the program rather than problems in the JVM.

Especially Swing code is often extremely poor and inefficient leading to excruciatingly slow GUIs.
 
Sounds like you guys have found a hammer in search of a nail. It always gets me to here people talk about tools, and never the problem or requirements. I use Java, C, Perl, PHP, and shell scripts, because languages are simple and easy to learn. What's difficult is attacking your problem correctly and meeting the requirements.

Java has been known to be slow, because there are numerous hacks who going around writing crappy Java code. It's easy to write crappy Java code and get it to work.

Strangely, the original post talks about the screen output being slow. It wouldn't surprise me to learn that he was working on a windows box outputting to a command window. In many versions of Windows there are screen output problems, which cause slowdowns that aren't related to the program that is running in the window. Perhaps we should have attacked the problem originally, instead of the tools?

 
It wouldn't surprise me to learn that he was working on a windows box outputting to a command window.

FYI: If you run a command window in full-screen mode (alt+enter), it's significantly faster.

Chip H.


____________________________________________________________________
If you want to get the best response to a question, please read FAQ222-2244 first
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top