Is Java Slow

from "Timing Trials, or, the Trials of Timing: Experiments with Scripting and User-Interface Languages" by Brian W. Kernighan and Christopher J. Van Wyk [1998] (http://www.cs.bell-labs.com/cm/cs/who/bwk/interps/pap.html)

"Our experiments do not support the folklore that Java interpreters are 10 times slower than C, except when the excruciatingly slow I/O libraries are involved; otherwise the ratio is much smaller. Using buffered I/O functions improves runtimes, but by no more than a factor of two. Just-in-time compilation can have a significant effect, usually beneficial."

I suspect DoubleBufferedGraphicsInJava is the most common reason for slow Java applications. -- PrestonBannister

Moved from JavaIsDead:

java GUIs do seem slow NetBeans (Forte?) feels sluggish, JBuilder feels slower now its all in Java (and they both ask for 196Mb+ ram!). On the other hand, server-side Java apps seem quite fast enough.

The server-side stuff doesn't have to use JavaSwing or JavaAwt.

That's right. And the big culprit is actually Swing. Swing is gradually being optimized, but, of course, that doesn't happen over night. Under 1.1, it's slow because it doesn't have Hotspot (I haven't tried it under IBM's 1.1 VM). Under 1.2, the Java execution is faster because of Hotspot, but Swing performance doesn't improve because the graphics are handled by the Java2D API, which is new and needs optimization. (One of the reasons Java2D is slow, ironically, is that a lot of it was written in C for performance, but that means Hotspot can't get to it to superoptimize it, and the back-and-forth between C and Java imposes a lot of overhead. One of the things they're doing to optimize it is rewriting C code in Java.)

I agree that Java GUIs don't feel quite as responsive as their C or C++ counterparts. But it's been a long time since things seemed really horribly slow. -- GlennVanderburg

Uhm...try going to excite games and running, for example, the cribbage game. This isn't exactly a high pressure app, but it crawls along just the same. I honestly can't figure out what makes it so slow. -- AnthonyLander

I agree that applets and Swing can often be sluggish. But I think that often the performance of Java applets (like the one you mention) could be largely due to poor programming. For example, I like to play Pop and Drop at Yahoo (http://games.yahoo.com/games/downloads/pd.html) and while it takes like 20 seconds or so to load, once it starts it's a seamless games playing experience

A Java applet? What browser? Don't judge Java by the speed of applets, please. I'd bet money that if they'd convert that page to use the plug-in and you have the 1.3 plug-in installed, it'd go.

At this point, I don't believe Java is the right language for a graphical application like Together. That doesn't mean that it is not right for any applications or that it will never be right for graphics intensive programs. Unfortunately, they went the wrong direction with Swing by bitblt'ing everything - crazy! They should have gone for platform adaptive instead of complete platform independence. I would rather have a UI that adapted to my system than one that worked the same on every platform, anyway! Fortunately, there are several libraries being worked on now that will correct this problem and be able to use the compiled resources and windowing primitives of whatever platform it is running on. Either way, while Java may die someday, it will have little to do with C# or .NET. I predict that these will never be supported on as many platforms as Java. In fact, I doubt if we will see any successful .NET VM implementations for platforms other than Windows for a few years. I mean, why would this time be any different? -- RobertDiFalco

Java is not just a language (OK, depends upon the argument you want to make, but that would be Sun's answer). 'CLR' sounds suspiciously like 'JVM' to me, so both are "in the right place". Java, the language, is not cross-platform, but then no other language is, either. Cross-platform is about tools (interpreters, compilers, etc.) - the tools have to be there to get cross-platform done. Anyway, Java, the language, does not necessarily have to be the source that is converted to bytecodes to be run by the JVM. There exist others: Jython, IBM's Rexx, etc., which compile to Java bytecodes.

That being said, I definitely need to read up on .NET. I used to be a Microsoft-head, but converted to full-time Java-J2EE-head a couple of years ago. Probably could use some balance. -- MikeThomas

: Speaking as someone who supports up to a dozen platforms depending on the shifting winds, the only portable language is ANSI X3J11'88 C, and a subset of that even. -- SunirShah

When it comes to GUI speed, there's good news for the Java people. I tried the Java1.4RC1 with JEdit and it was really damn good! 1.4 really takes Swing performance where it should have been from the beginning. -- DanielFrisk?

IBM's open source Java EclipseIde uses their JavaSwt for graphics. It seemed a much more efficient and elegant implementation of gui. I don't agree that JavaIsDead, it's like a vampire, it spreads. There are many excellent open-sourced IDEs, servers, and frameworks in Java. -- Sesh

I worked on the SWT team when I was at OTI when they were working on what I guess is now called Eclipse. I doubt it's changed much since I was there. Think of SWT as JavaAwt done properly (for some definition of properly, such as maybe again - it seems like everyone has rewritten AWT), but it doesn't meet the same requirements as JavaSwing as it uses native widgets. You can find out more from the SWT articles on http://www.eclipse.org/articles/. I find it funny that they changed the meaning of the acronym to be Standard Widget Toolkit. -- SunirShah

There's something: I could never figure out why Swing refused to use native widgets. I understand the 'native widgets vary in features and support' line they give, but why wouldn't you emulate then? Oh well, I guess that's why there's SWT... now if only I could convert AWT's image to SWT's image in under 50 lines of code. :-) -- WilliamUnderwood

I can't speak for the Swing developers, but a major reason that lightweight components are better than the heavyweight (native) components is that they don't use system resources. If you use a heavyweight component, the JVM has to track the resource, which can complicate garbage collection. In fact, you can still get Swing to create heavyweight components (for example, a ComboBox that extends outside the edge of the window when opened). This causes no end of problems getting the component to garbage collect correctly or in a timely manner. This is not a Swing problem - it exists in AWT as well. -- JoshSegall?

The big problem with AWT was that you can't cram every native widget hierarchy into a common API and end up with something that meets basic user expectations. WORA assumes anywhere is pretty much the same as anywhere else. -- EricHodges

One thing that's slow relative to CeePlusPlus: some maths functions: exp(), log(), pow(). This is because of precise specification of error tolerances that mean strict Java implementations, on the x86 at least, will run slower than CeePlusPlus implementations.

Another minor point: didn't Sun originally create Java for embedded applications like VCRs and microwave ovens, then give up on it because of the sluggishness of the VM?

See link for a company that uses Java for embedded apps but not how it was meant to be used. Instead they compile Java into "C macros" and then compile with the C compiler for the embedded platform:(http://www.eet.com/at/c/news/OEG20030311S0041). You can even build COM objects from the resulting code: http://www.advancedcybernetics.com/JavatoWindows.htm --AndrewQueisser

From the EE Times article:

: "I'm not saying a Verilog compiler would produce optimal FPGAs from our C; you would have to bring in a hardware engineer to fiddle with it," said [ACG founder and chief technology officer Francis] daCosta. "But the potential is there."

Yeah. Right. "Fiddle with it," quotha. Hey, man -- even I don't try to "fiddle" with linkmap code produced by today's FPGA compilers. I leave that stuff to the hardware weenies who really know the operation of a particular device. There's one firm I know that produces 400 MHz video using Xlinx stuff that makes the Xilinx engineers bleed from the gums every time they talk about it. The video guys sure don't get that kind of performance out of Java. Heh.

It seems fast enough to participate in setting a new record for fast network data transfer: 17.77 gigabits per second: http://www.physorg.com/news85246030.html --StevenNewton