Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Java Performance Urban Legends

michael posted more than 11 years ago | from the boogie-man-will-get-you dept.

Java 632

An anonymous reader writes "Urban legends are kind of like mind viruses; even though we know they are probably not true, we often can't resist the urge to retell them (and thus infect other gullible "hosts") because they make for such good storytelling. Most urban legends have some basis in fact, which only makes them harder to stamp out. Unfortunately, many pointers and tips about Java performance tuning are a lot like urban legends -- someone, somewhere, passes on a "tip" that has (or had) some basis in fact, but through its continued retelling, has lost what truth it once contained. This article examines some of these urban performance legends and sets the record straight."

cancel ×

632 comments

Sorry! There are no comments related to the filter you selected.

hmmm (1)

fiftyfly (516990) | more than 11 years ago | (#5983405)

sounds like the optomizing needs a little, well, optomizing

Re:hmmm (0, Troll)

Anonymous Coward | more than 11 years ago | (#5983433)

Your Errors (1): Key:
  • error
    • corrected

Re:hmmm (0, Offtopic)

fiftyfly (516990) | more than 11 years ago | (#5983454)

sigh, I can't believe I misspelled it twice

Re:hmmm (5, Funny)

Planesdragon (210349) | more than 11 years ago | (#5983498)

sigh, I can't believe I misspelled it twice

No, you didn't. You misspelled it once; the second time is simply being consistent.

Misspelling it twice would be writing "optomizing" and "optomezing"

Re:hmmm (1)

fiftyfly (516990) | more than 11 years ago | (#5983602)

sigh, I can't believe I misspelled it twice No, you didn't. You misspelled it once; the second time is simply being consistent. Misspelling it twice would be writing "optomizing" and "optomezing"
Actually, come to think about it, it's more like a typo in a lookup table. No, no, I've got it - it's actually not catching an error in an inlined macro until link time.

<sigh/>

As a matter of fact I am in the basement just now...

Gosh I love this (-1, Offtopic)

Anonymous Coward | more than 11 years ago | (#5983408)

First Java post. How do you like this java performance?

Re:Gosh I love this (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#5983468)

Slow... as always

I only have a Pentium II 266mhz and 32 megs (0, Troll)

zymano (581466) | more than 11 years ago | (#5983500)

Yes it sucks to run java but no one uses java applets anymore. The killer app is java server side ecommerce. It's beating Microsoft so we should like it!

Re:I only have a Pentium II 266mhz and 32 megs (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5983558)

Why would a Microsoft hater have zappa333@hotmail.com as his e-mail address?

My favorite (-1)

Anonymous Coward | more than 11 years ago | (#5983410)

Was the one about the guy who drank java and pop rocks, and exploded. But, another good one was the time that wrote a java application that made my web browser not slow to a crawl.

Re:My favorite (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5983712)

LOL hey man thats a funny one mod that shiat up mang.

Java for Applications.... (0, Troll)

NicotineAtNight (668197) | more than 11 years ago | (#5983421)

has poor start up time, and requires an absolutely massive amount of memory. That, and garbage collection makes almost-real time ("soft" real time I believe is the technical term) UIs more difficult than they should be.

Also, Swing is a bloated pig.

JNI (native interface) can swap huge numbers of arrays back and forth if you don't test for it and have a fall-back mode.

These are huge pitfalls, even on our multi-GHZ beastly desktops. But they are the only pitfalls.

String requires careful attention.

That's all she wrote folks, I didn't even read the article (should probably post anonymously!) but I've spilled the beans. Nothing else to say.

Just read the article... (0)

Anonymous Coward | more than 11 years ago | (#5983430)

Fluff. My post is superior.

Re:Java for Applications.... (2, Insightful)

Anonymous Coward | more than 11 years ago | (#5983460)

Also, Swing is a bloated pig.

SWT [eclipse.org] rules!

SWT makes me want to wretch (1)

NicotineAtNight (668197) | more than 11 years ago | (#5983479)

I wouldn't mind if it was pure Java, but that's far from the case. Pure Java GUIs can be fast (but memory intensive), it's a shame that SWT is currently the only "alternative" to Swing because it's such a horrid choice to make - Slow but pure or Difficult to use, platform-dependent and fast.

Re:SWT makes me want to wretch (1, Informative)

Anonymous Coward | more than 11 years ago | (#5983537)

SWT isn't platform-dependent. Look it up.

But it's BEATing Microsoft ! (1)

zymano (581466) | more than 11 years ago | (#5983486)

sounds good to me.

Java vs. RAM (5, Informative)

kwerle (39371) | more than 11 years ago | (#5983549)

has poor start up time, and requires an absolutely massive amount of memory. That, and garbage collection makes almost-real time ("soft" real time I believe is the technical term) UIs more difficult than they should be.

Oh, good, another one to shoot down. While I don't have any numbers at all, I know that Apple 'fixed' this problem to an extent by making parts of java shared, just like any shlibs. This alleviates the 14 apps, 14 bags of shit problem to some extent.

Apple then returned the changes to SUN, who rolled them into 1.4.x.

I wish I had numbers. Sorry.

Re:Java vs. RAM (0)

Anonymous Coward | more than 11 years ago | (#5983619)

Rolled them into 1.4?
Ha! I was talking about 1.4's slowness in starting up.

Re:Java vs. RAM (3, Funny)

MonopolyNews (646464) | more than 11 years ago | (#5983648)

don't you understand... there is a Special Case where it will start something up fast... if it's already been started up... so if you start the app 3 times... you have a 66% startup time improvement! you have to study these things closely. Also, VMs can run as fast as compiled code, after all, they are compiled code, but they just won't run your Java code as fast. I mean, the java code can run just as fast, as long as your JVM is optimizing on the fly based on dynamic code profiling... of course, it won't seem faster because the dynamic profiling and recompiling is expensive, but the original code is running faster!

Re:Java vs. RAM (-1)

Anonymous Coward | more than 11 years ago | (#5983676)

Blah blah blah. It's amazing how many people preach Sun's marketing-speak without getting paid for it. The only hope for Java is GCJ. What good is a JIT when you run the same application over and over again and have to compile it with javac anyway? Just compile the damn thing once to native code and be done with it. Screw the 40 Meg JVM - just ship a 2 megabyte executable instead.

Re:Java vs. RAM (0)

Anonymous Coward | more than 11 years ago | (#5983694)

Unfortunately Hello World still uses 8mb of ram.

Re:Java for Applications.... (5, Interesting)

linhux (104645) | more than 11 years ago | (#5983564)

Exactly how does "string require careful attention"? I've seen this statement a couple of times, but only to suspect that many people don't really understand what Java Strings are.

The first mistake, of course, is that people think that (a == b) == a.equals(b) which is, of course, only true if a and b are constant strings or one have invoked intern() on them.

The second is to not realize that string concatenation with the "+" operator is a special case and only syntactic sugar for StringBuffer operations. Thus, someone not familiar with Java may accidentally generate huge amount of StringBuffer objects in loops.

However, both these things are very fundamental Java knowledge and among the first thing you learn when studying Java. It's obvious that you don't start coding serious Java without knowing how try..catch..finally works, and equally obvious that you should the know about the deals with the String class.

Re:Java for Applications.... (4, Interesting)

BrookHarty (9119) | more than 11 years ago | (#5983575)

Really, I cant tell if the java programming language is slow, Synchronization is really slow, Declaring classes or methods final makes them faster or Immutable objects are bad for performance.

But I can tell you, the that almost every Administration application that runs java, sucks out my soul. Trying to run java applications over X at long distances makes me want to commit suicide. (Lucky theres VNC, so its almost usable...) (I think its a Shared memory problem with the way it works with X windows.)

Then there is the damn JVM's that each app needs, and how i can have multiple versions loaded, so each application works correctly. Java 1.1/1.2/1.3/1.4 and now 1.5 should take even more disk space. Doesnt seem anything is upgradable in java.

And lets not forget, about how Java likes to interact with all custom window manager replacements on windows. For some reason the screen flickers every time you run a java app. (Havnt seen any answers, but it messes with lightstep, blackbox, geoshell, and even stardock applications.)

Humm, and cut/paste sucks, yes you can use key combos, but sometimes in windows, its nice to select all, and copy. (Minor bitch, but still annoying when you have switch ways of doing things...)

If you cant have command line, and you must have a GUI, for gods sake use a HTML. I now make it a point to go with vendors without Java interfaces, they clearly dont use their own products on a day to day basis.

BTW, i said java Interfaces, not Java Beans, etc. We have java running on solaris, works fine, other than the memory leaks. Its the Admin applications that use Java that are crap.

Re:The problem with exporting work (1)

pyrrho (167252) | more than 11 years ago | (#5983677)

What you fail to understand is the real world doesn't matter. There is a special case in which that might not be true and someone might code the JVM that executes the special case, so the horrors you speak of are superfluous!

Enough about the things Java can never fix. (5, Insightful)

Anonymous Coward | more than 11 years ago | (#5983625)

I'm all for calling a spade a spade, but you can't have your cake and eat it too.

JNI is the NATIVE INTERFACE. For those that don't already know, that's the interface to the underlying operating system. If the OS misbehaves, hiccups, or is inconsistent, when did it become JAVA's responsibility to clean up? When somebody decided that JAVA was getting a black eye because OS call foo(bar) was crashing the application, or better yet didn't behave exactly like foo(bar) on every OS that provides the JVM.

Don't like AWT? Well mabye that's because it's built on top of JNI. Enough said.

Don't like Swing? Well you'd better like AWT. If you don't want the OS to do your GUI work and you don't want the JVM to do your GUI work, mabye you should just get a dry erase marker. You can draw the boxes you need on the screen provided you use a tissue between display updates.

String requres no more attention than any other bit of JAVA code. If you create dozens of objects for the sole purpose of garbage collection, you either just learned JAVA, you're unaware of what you're doing, or you don't care.

And about garbage collection. JAVA's garbage collection may not be your cup of tea, but neither are the memory leaks that are still being cleaned up in systems that lack automatic garbage collection.

So pick your posion. If JAVA isn't perfect, that dosen't make it horrible. JAVA is a good language by most standards, but be honest by stating that it isn't good by your standards.

My biggest reason for liking JAVA is that it forces people to stop writing bad C code. Which is exactly what it was designed to do.

Re:Enough about the things Java can never fix. (2, Insightful)

Paleomacus (666999) | more than 11 years ago | (#5983654)

I agree JAVA is good at what it's intended to do. Preventing average programmers from blowing things up.

Re:Enough about the things Java can never fix. (2, Interesting)

pyrrho (167252) | more than 11 years ago | (#5983726)

>My biggest reason for liking JAVA is that it forces people to stop writing bad C code. Which is exactly what it was designed to do.

this is what I dislike about it. I don't like languages built to force me away from a bad habit, it means I've been forced into (someone else's idea of) the perfect habit. I have yet to find the perfect habit.

The real solution for bad C/C++ code (I slipped C++ in there on purpose) is to learn what you are doing. If you can't learn the ins and outs of procedural logic than don't create an imperitive language, you still have the the real pitfalls still present, and create a new paradigm altogether at a higher language, like Zope.

There are good problems that VMs address, but they are niche areas (dynamically distributed code that can benefit by using heterogenous networds, and certain idioms like self modifying code... somehow I don't think the joy of self modifying code is what Java is about, but then, I'm told again and again how Java will be as fast as C++ when the JVM's dynamically recompile and optimize code as it runs... loluck), and not general purpose areas.

I assume you know (3, Interesting)

Anonymous Coward | more than 11 years ago | (#5983650)

that the operating system duplicates the amount of memory reported for each thread in a JAVA program?

For example, should I have a program that has 8 threads and the whole thing uses 28 mb of memory.
A process listing shows 8 entries each using 28 mb of memory, when in reality only 28 mb and not 224 mb (8 * 28) of memory is being used.

Before you blame this one on JAVA too, you might want to know that it's a bug in the concept of process memory reporting (ie. the OS) not JAVA. The OS lists 8 scheduleable programs (the java threads) looking up the amount of memory each has access to (28 mb) without ever hinting that they are all using the same 28 mb.

To what extent does this exist in other languages? (5, Interesting)

Surak (18578) | more than 11 years ago | (#5983423)

I wonder to what extent this exists in other languages? For example, there is an oft-cited tip that says using persistent database applications with LAMP applications increases performance. I've found in actual practice that this depends on a lot of factors such as server load, amount of available memory, etc.

I remember in my Turbo Pascal programming days (heh) that a lot of people said that using Units would degrade performance. So I tried it both ways and it never really made a difference, for my applications anyways.

I'd say before taking someone's word for it on a performance enhancing technique, test it out. Because not everything you read is true, and not everything you read will apply to every environment or every application.

Re:To what extent does this exist in other languag (2, Insightful)

w42w42 (538630) | more than 11 years ago | (#5983557)

Good advice. People sometimes seem to want to solve the problem before knowing what the problem statement is. While their actions may not degrade performance significantly, they often times do not help.

I've learned over time that everything is relative. There is no cut and dried right and wrong in a lot of cases, but degrees of both. The real answer depends on your need, and not all needs are the same.

Re:To what extent does this exist in other languag (0)

Anonymous Coward | more than 11 years ago | (#5983675)

Well JAVA has features that are mostly missing in the languages that it is compared to.

So any time someone compares your programming environment to say, a car, you are experiencing what most people do to JAVA.

My favorite Java UL... (4, Funny)

ktakki (64573) | more than 11 years ago | (#5983426)

There was this one guy who worked for Sun Micro and was disappointed at how slowly Java ran on his Sparcstation, so he attached one of those JATO rocket engines...

k.

Re:My favorite Java UL... (0)

Anonymous Coward | more than 11 years ago | (#5983459)

That's an urban legend??? Dammit...

Re:My favorite Java UL... (0)

Anonymous Coward | more than 11 years ago | (#5983617)

I heard it was fast.

Re:My favorite Java UL... (0)

Anonymous Coward | more than 11 years ago | (#5983666)

Tell me about it! I tried installing a Solaris OS on an old Sparcstation, and X alone took 2 days to install! I can't say I know exactly how long the whole OS takes to install, because I turned the computer off after a week.

Source (1, Interesting)

Anonymous Coward | more than 11 years ago | (#5983434)

Post the source code here [sf.net] and all "urban legends" about it will soon dissappear.

did you notice (1)

andy1307 (656570) | more than 11 years ago | (#5983728)

One of the links in the sponsored content box on the left is "buy viagara online".

Java is Slow (4, Funny)

Anonymous Coward | more than 11 years ago | (#5983441)

Ok, so none of the things we thought were slow are really slow.

Then why the hell is it so slow?

Re:Java is Slow (1, Insightful)

Surak (18578) | more than 11 years ago | (#5983685)

Remember the DOS days? Was was GWBASIC so slow? Why were QuickBASIC programs so slow? Why, later, were Visual Basic programs so slow?

Because those versions of BASIC were all, essentially, interpreted.

Java is essentially an interpreted language, despite JITs and JNIs and whatever.

Interpreted languages are slow. That's why no one writes full-blown applications in BASH.

Re:Java is Slow (1)

Joe Tie. (567096) | more than 11 years ago | (#5983702)

Then why the hell is it so slow?

Swing.

Re:Java is Slow (1, Informative)

Anonymous Coward | more than 11 years ago | (#5983710)

I know it's a joke (and I'd mod it up if I could) but for those that are completely clueless...

JAVA was slow about 8 years ago, when most people who would have been early adopters where making their mind up whether to adopt JAVA or not.

Those that did, did so because the programming lanugage itself included features which made the worst kinds of common mistakes in C and C++ go away. Those that didn't, didn't because JAVA suffered from problems that are common to any new language. Unfortunately the extreme media spotlight and pressure to use the new (to most at that time) techniques of OOP only made the latter group dig in their heels and avoid any acknolwedgement that JAVA has (or even could) improve.

It's the same kind of mindframe that still has our company operating at half duplex (since a network card we bought in '92 dropped packets like crazy on full)

Memes (1, Insightful)

Zach Garner (74342) | more than 11 years ago | (#5983448)

Urban legends are kind of like mind viruses

Are you new here? Usually people call this kind of thing a meme.

Re:Memes (1)

ShallowThroat (667311) | more than 11 years ago | (#5983483)

True enough, heres a source to learn about them:
  1. http://www.aleph.se/Trans/Cultural/Memetics/alt. memetics.faq.txt

Re:Memes (1)

Zach Garner (74342) | more than 11 years ago | (#5983493)

Thanks for the link [aleph.se] .. I was to lazy to give a link in my original post.

Re:Memes (0)

Anonymous Coward | more than 11 years ago | (#5983723)

Calling memes memes is a stupid meme that i don't participate in sorry.

Urban Legend: IBM is unbiased regarding Java (-1, Redundant)

Teckla (630646) | more than 11 years ago | (#5983450)

Enough said. :)

-Teckla

The best tip (5, Insightful)

Anonymous Coward | more than 11 years ago | (#5983456)

The best tip in the article, which really applies to any language (even to choice of languages), is IMHO
"Save optimizations for situations where performance improvements are actually needed, and employ optimizations that will make a measurable difference."

-1, bloody obvious (2, Funny)

Michael's a Jerk! (668185) | more than 11 years ago | (#5983494)

Save optimizations for situations where performance improvements are actually needed, and employ optimizations that will make a measurable difference."

1) become a journalist
2) use common sense and lots of bullshit
3)????
4) profit!

The missing step appears to be get an MBA and go into management

Re:-1, bloody obvious (1, Interesting)

Anonymous Coward | more than 11 years ago | (#5983618)

If it's so bloody obvious, why does it need to be said? You'd be surprised how many times people "shoot themselves in the foot" writing things in C, in areas where Java performance is (now) ok. Or write something that needs the speed in C, but introduce bugs in optimizing something that would be better optimized by the compiler anyway.

Re:-1, bloody obvious (0)

Anonymous Coward | more than 11 years ago | (#5983681)

It may be bloody obvious, but there are still some people out there who still insist on writing everything in hand-optimized assembly language.

It doesn't help... (4, Interesting)

devphil (51341) | more than 11 years ago | (#5983457)


...when one of the first issues of Java magazine published an article explaining the Java object runtime model, but made it little more than a FUD-filled advertisement. (What killed it for me: claiming that C++ vtbls are always, in every implementation, done as a huge array of function pointers inside each obvject. It wasn't a typo, either; they had glossy color diagrams that were equally deliberately false.)

I think Java's a decent language, but it invented nothing new. Every language feature had been done before, and without the need for marketing department bullshit.

Re:It doesn't help... (4, Insightful)

Zach Garner (74342) | more than 11 years ago | (#5983474)

Every language feature had been done before...

One day, someone is going to come along with a really f'ing amazing language. Everyone will be talking about how great it is. And if you are lucky, it might have half the features that Lisp has had for ages.

Times change (4, Interesting)

onelin (116589) | more than 11 years ago | (#5983464)

I think a lot of the "urban legends" originated before CPUs were at a speed where it didn't matter. Past 500Mhz, as one professor put it, and the CPU starts being fast enough that handling Java doesn't slow it down significantly compared to before then...and now we're dealing with multi-GHz monsters.

What the article said is true - JVMs have improved a lot. They are getting better and better, even today. My friend likes to fool around with all these little 3d demos in Java and even the latest JDK (1.4.2 beta) suddenly offers big performance boosts over the previous JDK. The fact that I refuse to ever use a beta Java SDK is another story, though...so I won't see those performance gains for a little while.

Re:Times change (5, Interesting)

etymxris (121288) | more than 11 years ago | (#5983532)

JVMs are always improving, I'll definitely agree. But efficiency will always matter. I was writing my own regular expression parser (had to homebrew it for various reasons) that got statistical information from multiple megabytes of text data. Whatever performance improvement that could be made was noticed...a lot. Do you want to wait 60 seconds or 30 seconds for the results? It's a big difference.

No matter what, there will always be applications that strain our machines to the cusp of their abilities. And there will always be things we want to do that our machines cannot handle. It's only by performance tuning that these tasks can go from impossible to possible.

If John Carmack was forced to program in Java, for example, Doom would only now be possible. And Doom III wouldn't be possible for many more years. Performance matters. Not always, but often.

Re:Times change (1)

MonopolyNews (646464) | more than 11 years ago | (#5983663)

I don't understand why you would believe there is a magic CPU speed where something five times slower suddenly isn't five times slower! what are people thinking?

Re:Times change (1)

onelin (116589) | more than 11 years ago | (#5983692)

What exactly is it 5 times slower at?

What was meant was that CPUs have evolved since Java's origin, and different CPUs handle different code in different ways. P4's are faster at encoding. Athlons are better at a lot of games. CPUs changed as they got faster, and now they handle java with less slowdown than they used to, as compared to say, C++. At least that's the illusion I was trying to say *might* be true.

Damn, now I'll be up all night pitting Java up against C++.

Java's memory usage (2, Interesting)

zymano (581466) | more than 11 years ago | (#5983472)

Does anyone know why Java isn't more memory efficient? Lack of pointers?

Isn't the memory usage one of negatives of java?

While I don't care too much for java's wordy verbose syntax , anything that competes with Microsoft is A-OK in my book.

If any of you think Sun is making a ton of money on java , check this link out. [com.com]

I am beginning to feel sorry for SUN. They are also in some economic hard times laying off alot of people.

Re:Java's memory usage (3, Insightful)

onelin (116589) | more than 11 years ago | (#5983571)

If for nothing else than Java competing with .NET, I'm happy it's there. It's not my favorite language, but I'll certain defend that it isn't as bad as most people think it is.

Re:Java's memory usage (5, Insightful)

fishbowl (7759) | more than 11 years ago | (#5983699)

>Does anyone know why Java isn't more memory
>efficient?

Well, java applications tend to use a whole lot of memory compared to C++, because of the way objects are allocated, and because there is no control over the details of allocation available to the programmer. Java Objects tend to be pretty heavy, partly because every Object carries a virtual table (to implement polymorphism, reflection, etc.) and also because every Object has the overhead required for the thread synchronization model.

As to whether or not it is "efficient", it depends on your point of view. For some applications, the java memory model is very efficient. Java goes to great lengths to ensure coherence among unsynchronized reads and writes in multiprocessor systems, and it must accomplish this via completely abstract means. Platform independence comes with a price, and a big part of that price is that high level optimizations become difficult or impossible to implement. JIT's and native libraries may help, but, there is still a hugely complex problem in exposing any sort of high level control of those things to the programmer. That is, in my opinion, the main reason that it is not fair to compare Java performance to C++ performance. It is not an apples-to-apples comparison. I think it would be reasonable to compare a transaction system written say, in J2EE under an app server, to say, a C++ transaction system running under an ORB. I think you will find that Java compares favorably in that context, and is simpler to write and maintain. I believe that makes it an excellent choice for business software.

If your model did not require threads and locks, for instance, you could do away with much of the complexity.

There is a whole heck of a lot going on under the hood to enable concurrent processing. You write your code as if it will execute sequentially, but there are many situations where operations will be interleaved, optimized to execute out-of-order (or even optimized away entirely).

The java implementation is much more concerned with Visibility, Atomicity, and Ordering, than it is with raw performance. If you really want to learn how it works, the specification is not a difficult read. Most of the details about memory are here:

http://java.sun.com/docs/books/jls/second_editio n/ html/memory.doc.html#30206

Urban MySQL vs. Urban PostgreSQL (4, Interesting)

philovivero (321158) | more than 11 years ago | (#5983485)

Interesting. As a guy who's been a die-hard PostgreSQL for a number of years, and who recently accepted a job doing hardcore MySQL administration, I was dreading it, because everyone knows MySQL has bad transaction management, horrible administration nightmares, and is only good for developers.

And I'm sure MySQL DBAs all know PostgreSQL is slow, bloated, and is only good for huge database rollouts.

Except, well. You get the gist. I'm replying to this article because I now know first-hand that both camps are getting a lot of it wrong.

I've written up what began as a final in-depth studied proof that MySQL wasn't ready for the corporate environment (because I'm a PostgreSQL guy, see?) but ended up reluctantly having to conclude MySQL is slightly more ready for the corporate environment than PostgreSQL!

The writeup [faemalia.org] is on a wiki, so feel free to register and add your own experience. Please be ready to back up your opinions with facts.

Re:Urban MySQL vs. Urban PostgreSQL (1)

MBCook (132727) | more than 11 years ago | (#5983534)

But Linux people always say that MS stuff always crashes. And MS people say mean things about Linux.

Does this mean Windows doesn't crash?

Wow... My eyes have been k#dK%SDJ3(&s*x@M NO CARRIER

Java is a bloated POS (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#5983488)

Just use C.
Or better yet, assembly.

Absolut no content (1, Insightful)

TheSunborn (68004) | more than 11 years ago | (#5983497)

Interesting. A text that say that some things in java are not as slow as people belive, and yet it fail to deliver any prove anything. For ekample it say: synchronized methods are not slow, and yet it include no benchmark/test to backup that claim.

And about the strings example:
If you want't to prove that the Immutable string class is not slow the right way to do it is to make a program that make a lot of string operations and then compare the speed with one of the non Immutable string classes for java that exists.

I really wish that the slashdot editors would read the stories and dismiss the one widtout any information.

(Yes I know, the slashcode is free, so I could just make my own news-site but life is to short, and the studie take to much time.

Re:Absolut no content (1)

TheSunborn (68004) | more than 11 years ago | (#5983582)

(A reply to myself)
I actuelly tried to run the benchmark
Synchronized took 213 ms
Unsynchronized took 22 ms

So you can conclude that calling a synchronized function is 10 times as slow, as calling one that is NOT syncrhonized. But this does NOT matter because the actuell time it take to call a synchronized method is so small. It calls
the synchronized method 10000000 times in ~200 meaning that you can call a synchronized method 50000 times each ms(If you already got the lock)

So in any real program the work done in the function would far outweight the small extra time it take to call a method.

Now I just wish they would make all the swing methods synchronized so swing would be thread safe :-}

Re:Absolut no content (0)

Anonymous Coward | more than 11 years ago | (#5983590)

Which jvm did you use, and on which OS?

Re:Absolut no content (1)

TheSunborn (68004) | more than 11 years ago | (#5983637)

Oh, sorry forget that. It is

java version "1.4.1_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1_01-b01)
Java HotSpot(TM) Client VM (build 1.4.1_01-b01, mixed mode)

on redhat linux 7.3

Re:Absolut no content (0)

Anonymous Coward | more than 11 years ago | (#5983583)

Well, the author does point to an article in the resource section that tries to measure this.

Re:Absolut no content (1)

TheSunborn (68004) | more than 11 years ago | (#5983598)

Well but as far as I could see only for the synchronized example. It would be far more interesting to se some benchmark on the String class.

Antidote (4, Insightful)

Henry V .009 (518000) | more than 11 years ago | (#5983499)

One thing to remember is that Java is a 'marketed' language. Hence, be aware of inevitable corporate propaganda. That's not to say that Java is bad, but it is heavily pushed.

Here's a bit of an antidote: Why Java will always be slower than C++ [jelovic.com]

Sun is not making much off of java (1)

zymano (581466) | more than 11 years ago | (#5983524)

news article [com.com] . BEA is.

Re:Antidote (1)

Col. Klink (retired) (11632) | more than 11 years ago | (#5983697)

I love the fact that the article you linked to includes one of the Urban Legends in the original article:

Urban performance legend #2: Declaring classes or methods final makes them faster

From your link:

I received a lot of feedback about this article. Here are the typical comments, together with my answers:

"You forgot to mention that all methods in Java are virtual, because nobody is using the final keyword."

The fact that people are not using the final keyword is not a problem with the language, but with the programmers using it. Also, virtual functions calls in general are not problematic because of the call overhead, but because of lost optimization opportunities. But since JITs know how to inline across virtual function boundaries, this is not a big deal.

Java is slow (3, Interesting)

etymxris (121288) | more than 11 years ago | (#5983502)

I've programmed in Java before, and love it as a language. Unfortunately, even in the newer iterations of the JVM, you simply cannot trust the virtual machine to get rid of objects efficiently. If you are doing some heavy processing, you simply will exhaust all memory on your machine, even if you explicitly set references to null.

If there is an "inner loop" of your application that needs performance above all else, and you need to program it in Java for whatever reason, there are two things you should get rid of:
  1. Memory allocations
  2. Function calls
Of course, if you can do this in C/C++, it will also improve performance, but it is not as critical to be so careful in these lower level languages.

I've just found that you can't trust the garbage collector, no matter how good people say it is. People have been saying it's great since the beginning of Java, and now they say, "It wasn't good before, but it is now." And they'll be saying the same thing in 3 more years. No matter what, the opportunistic garbage collection of C/C++ simply leads to better performance than any language that tries to do the garbage collection for you.

Re:Java is slow (0)

Anonymous Coward | more than 11 years ago | (#5983510)

This is flat out wrong, what is "heavy processing", please describe what causes your machines to run out of memory?

Re:Java is slow (3, Informative)

etymxris (121288) | more than 11 years ago | (#5983556)

This is flat out wrong, what is "heavy processing", please describe what causes your machines to run out of memory?
This is simple. Here are some examples I worked on:
  1. A tax adapter that did operations for each order. Setting a load tester against the server caused the machine to max out on memory. So I eventually had to create my own pool of objects to stop them from getting touched by the garbage collector.
  2. Text parsing/processing that operates on each line of many megabyte files. When done with mutable String objects, it kept increasing memory as a function of time, never reducing the memory load. It's not like I kept references to these objects. I had to reprogram it to not keep allocating objects for each line.
I'm sure others have their own examples to contribute.

Re:Java is slow (0)

Anonymous Coward | more than 11 years ago | (#5983576)

1) I dont think you understand object oriented programming. It sounds like you were creating tons of crap when you didn't need to be. Also try tuning your garbage collector.

2) ... and? Again tune your garbage collection. Whats wrong with using up all your FREE memory, it isn't doing anything else.

I run a *very* complex monte carlo simulation in java, these problems don't exsist for me when acting on THOUSANDS of funds.

Re:Java is slow (1)

etymxris (121288) | more than 11 years ago | (#5983638)

Whats wrong with using up all your FREE memory, it isn't doing anything else.
What you lose by taking up free memory is the potential for needed operations. For example, your JVM won't know that your browser needs more memory to allocate that huge PDF. Ideally, it should realize that your waiting for memory and start getting agressive about garbage collecting. But it doesn't know this. Instead, the operating system starts swapping stuff out to disk, making everything slow.

...tune your garbage collection
I really shouldn't have to. I don't have to in C/C++ or (godforbid) VB. But even if I did, there would still be problems. On an inner loop I can't use any value objects since they get allocated on the heap rather than the stack. Stack allocation is O(1), heap allocation is O(N). With an inner loop, this O(N) turns into O(N^2), and so on, while the stack allocation stays at O(1).
I run a *very* complex monte carlo simulation in java, these problems don't exsist for me when acting on THOUSANDS of funds.
I don't doubt that Java can be made to be efficient. But you simple can't go in programming it with the same assumptions that you would with other languages. The garbage collector was supposed to make things easier. It made some things easy, but it made many other things harder.

Re:Java is slow (0)

Anonymous Coward | more than 11 years ago | (#5983715)

It sounds like you're talking out of your ass.

Re:Java is slow (2, Informative)

Curt Cox (199406) | more than 11 years ago | (#5983668)

Not to be a pedant, but I doubt either of these were GC bugs.
  1. Your description is a bit too vague, for me to guess with much certainty. I bet you had some finalize methods that were preventing the GC thread from reclaiming your objects fast enough. This situation should be easier to diagnose and prevent than Sun currently makes it, but it isn't really a GC bug. Effective Java has a nice write-up on this problem. If you really think it is a GC bug, try creating a simple test case that demonstrates it. Java has plenty of bugs, but in my experience, trying to construct a simple test case for submission to Bug Parade will often demonstrate that you didn't really understand the problem.
  2. This sounds quite a bit like either this [sun.com] bug, or a close cousin. It is quite nasty, but really a bug in the java.lang.String code, and not in the GC.

Re:Java is slow (5, Informative)

larry bagina (561269) | more than 11 years ago | (#5983565)

I think he's talking about something like this:

while(true)
{
Object o = new Object();
/* snip */
o = null;
}

The GC won't free the memory in realtime (or, sometimes, ever), as would be the case for C++/C with new/delete malloc/free.

Re:Java is slow (1)

etymxris (121288) | more than 11 years ago | (#5983660)

Yeah, that's pretty much what I was talking about.

Ok, so if Java doesn't suck speed wise.. (2, Funny)

Large Green Mallard (31462) | more than 11 years ago | (#5983514)

It must be all these Java "programmers" that University CS departments world wide keep churning out that couldn't write a well performing program if their life depended on it?

*looks at Limewire*

*looks at administration applets written by Sun which don't work over X11*

jav vm sucks (2, Interesting)

Anonymous Coward | more than 11 years ago | (#5983516)

Fact: Due to similarities of the MSIL/Java Bytecode, Java bytecode can eb converted into MSIL bytecode. (though not vice versa, due to higher expressiveness of MSIL).

Fact: Valenz and Leopold did a survey (summarrixed in the most recent issue of Dr Dobbs) whereby Java bytecode programs were converted to MSIL, and the .NET, Rotor, MONO, Sun, Blackdown, etc. VMs were compared. In each case, Microsoft's .NET VM had a 5-20% speed increase over the best java VM, and even the MONO and Rotor VMs had a 2-15% speed increase.

Why were there so many negros in The Matrix? (-1, Troll)

Anonymous Coward | more than 11 years ago | (#5983519)

nt

Re:Why were there so many negros in The Matrix? (-1, Offtopic)

texwtf (558874) | more than 11 years ago | (#5983561)

It's spelled "negroes" dumbass

Performance is ok, but memory footprint... (3, Interesting)

Kjella (173770) | more than 11 years ago | (#5983555)

Running Freenet and only freenet

javaw.exe - Mem usage 70,244K
java.exe - Mem usage 9,808K

According to task manager. Granted, now I got 512 to take from but it's still eating up much more memory than anything else.

Kjella

kind of right, and that's a problem (3, Insightful)

g4dget (579145) | more than 11 years ago | (#5983559)

While the article has a number of glaring errors, the general point the author is making is right that in terms of raw computer performance, Java has become quite fast.

But that's not really a good thing. Sun pushed on the JIT on the theory that that would address performance problems. It didn't. The Perl and Python runtimes are much slower than Java's, but Perl and Python applications generally start up much faster and are considerably more responsive.

Java is as sluggish as ever, and more bloated than it has ever been. What is really responsible for Java's poor performance for real-world applications is its class loading, memory footprint, and just plain awful library design and implementation.

I'm glad it's slow... (1)

jafo (11982) | more than 11 years ago | (#5983588)

Back in mid to late 1997, Java performance was horrible, particularly on Linux. I remember being very happy with the performance of my development box (dual PPro 200, 200MB of RAM) at the time, except when I was running Java apps. It also used tons of RAM just to start an application, and then it leaked...

I'm sure that all of this has gotten better in the 5 years since then. It doesn't really matter to me though... After 6 months of trying to be happy with Java, I switched to Python. It's working fantasticly for me.

Sean

Profile your software, don't guess (2, Insightful)

HidingMyName (669183) | more than 11 years ago | (#5983597)

Finding where your software spends most of its time can be hard. Having a tool measure resource/time consumption of the regiouns of source code is critical in finding bottlenecks and improving performance.

Error in title (3, Funny)

cperciva (102828) | more than 11 years ago | (#5983607)

"Java Performance Urban Legends" should read "Java Performance is an Urban Legend".

Bullshit (2, Insightful)

vlad_petric (94134) | more than 11 years ago | (#5983610)

Why ? Because it depends so much on the performance optimizations the JVM employs.
Let's take them one by one:
<br>
<LI> Final methods and classes - when you call a final method from the same class you save a lookup in the virtual method table (there is no doubt about what method is going to be called, as it couldn't have been overwritten in a descendent), and furthermore you can inline that method. On a "stupid" JVM (read: from Sun) you won't see any difference, on an optimized one you will.

<LI> Synchronization can become a bottleneck on SMP systems, because it implies cache synchronization (exiting a synchronized block
is a memory barrier) - you clearly aren't going to see it on a single processor. But not using synchronization is just as bad (you should use synchronization with <b>all</b> variables that are shared, because you do want memory barriers for correctness)

<LI> Immutable objects - this one clearly depends on the garbage collector that you use.
<p>
Conclusion: the performance of these tricks depend on two things - your JVM and Amdahl's law (how often are these improvements going to manifest themselves)
<p>

Java Performance is an oxymoron (0)

texwtf (558874) | more than 11 years ago | (#5983633)

The thing that really chaps me is not that java is painfully slow, which it is. It's that it is painfully slow as well as a broken and otherwise crappy language that is painfully slow to program in versus other interpreted speed languages. It doesn't _have_ garbage collection, it _is_ garbage collection. I hate java, and I _despise_ the fact it is pushed by hard marketing rather than utility. Naturally I will get moderated down for speaking ill of the slashdot pet language, so you will never read this anyway.

Worst...disproof...ever (4, Informative)

Effugas (2378) | more than 11 years ago | (#5983646)

If you're going to rebutt some urban legends, perhaps it might help to go online, check out Snopes, learn how to argue against things...

Yeah. Lets look at this article:

Myth 1: Synchronization Is Really Slow
a) Ummm, well it was slow...but not anymore!
b) As the programmer, you have no idea what code is eventually going to be run. (Who knows! It might be FAST!)
c) Who cares about the actual numbers; it's only a constant overhead! (This is actually a good point -- the sync'd method isn't doing anything, so the syncing can't amortize its penalty across any amount of work. But...still..."regardless of the actual numbers"?!?)
d) But...but...you need to sync! Your programs will crash if you don't!

Myth 2: Declaring methods "final" speeds them up
a) Nuh-uh!
b) I don't see a benchmark anywhere! (Nor, apparently, can I write one.)
c) But...but...what if someone wants to extend your class?

Myth 3: Immutable Objects are bad for performance
a) It could be faster. It could be slower. Maybe you won't be able to detect a difference.
b) The myth comes from a fundamental truth about how Java does many things really really slowly.
c) StringBuffer creates objects too...ummm...in the corner case where the default buffer size isn't big enough to handle the added data, and the buffer wasn't preconfigured to store sufficient amount of data...heh! Look over there! *runs away*
d) As the programmer, you have no idea what the garbage collector is eventually going to do. (Who knows! It might be FAST!)
e) But...but...you're sacrificing object oriented principals!

I was really waiitng for Myth 4..."Who needs performance! It's a Multi-Gigahertz PAHHHTAY!!!" But apparently that got cut.

I've got a data point for 'em. You know Nokia's n-Gage Gameboy Killer? Hehhehe. Not _only_ did they completely forget to throw in any hardware acceleration for sprites -- heh, an ARM is fast enough -- but it looks like you're supposed to write games in Java.

So, yeah. Puzzle Bobble @ 5fps. But I'm sure it's very elegant code :-)

--Dan

P.S. On the flip side, I'm playing with an app whose 2D GUI was designed with GL4Java...it's a work of art; faster than Win32, at least for tree manipulation. Java can be a beautiful language once its relieved of the duty of actually computing anything...

Truth AND Consequences (4, Interesting)

fm6 (162816) | more than 11 years ago | (#5983652)

There are many reason why "urban legends" (why the quotes? explanation shortly) spread the way they do. Unfortunately, this article demonstrates one of the least forgivable reasons: people often get sloppy about their facts. It's inevitable that facts will get distorted as they go from ear to mouth to ear to mouth. But there's no need to hurry the process!

What's sloppy about the article? Well first of all, Goetz asserts " even though we know they are probably not true, we often can't resist the urge to retell [urban legends]". Where in Hades did he get such a silly idea? Some half-remembered sociology book? Everybody who's ever told me an urban legend really believed in that exploding microwave poodle or the dead construction workers concealed in Hoover Dam. I myself remember feeling rather peeved when I heard the sewer alligator legend debunked.

Second, perfomance myths are not "urban legends". ULs are third-hand stories that are difficult to debunk because the actual facts are hard to get at. "Facts" that people can check but don't are just myths or folklore.

Anyway, here's my favorite performance myth: "more is faster". The most common variation of this is "application performance is a function of CPU speed". Ironically enough, I encountered this one when I was working at JavaSoft. Part of my job was to run JavaDoc against the source code to generate the API docs. The guy who did it before me ran it on a workstation, where a run took about 10 hours. Neither of us had the engineering background to really understand why this took so long. He just took for granted that it was a matter of CPU cycles. I knew a little more than him -- not enough to understand what was actually going on, but enough to be skeptical of his explanation.

Eventually, I put together the relevent facts: (1) JavaDoc loads class files to gain API data, using the object introspection feature; (2) the Java VM we were using visited every loaded class frequently, because of a primitive garbage collection engine; (3) forcing a lot of Java classes into memory is a good way to defeat your computer's virtual memory feature...

Eureka! I tried doing the JavaDoc run on a machine with enough RAM to prevent swapping. Run went from 10 hours to 10 minutes.

Another variation of this myth is "interpreted code is slower than native code". That bit of folklore has hurt Java no end. If your application is CPU-bound, you might get a performance boost by using native code. But, with the obvious exception of FPS games, how many apps are CPU bound?

Here's another variation: "I/O performance is directly proportional to buffer size". At another hardware vendor I worked for, one of our customers actually filed a bug because his I/O-bound application actually got slower when he used buffer sizes greater than 2 meg. It was not, of course, a coincidence that 2 meg was also the CPU cache size!

Yeah but... (4, Insightful)

wideBlueSkies (618979) | more than 11 years ago | (#5983670)

OK, after reading everyones thoughts about Java's performance challeneges, I have to say that I agree, it is a slow language.

However, what I really dig is the library. Sockets, Strings, half a billion data structures, numeric and currency formatting, Internationalization and Localiztion support....
And there's always the JNI if I need to optimize in C.

Not to mention servlets, JSP's and JDBC.

You gotta' admid that this is all great stuff. So for certain applications (specially on the server) the benefits of the library far outweigh the performance problems of the sandbox.

Yeah, C++ has a great library too. But the Java library is so damned easy to use.

Seductive the dark side is.....

Here's an URBAN MYTH I SAW WITH MY OWN EYES (0)

Anonymous Coward | more than 11 years ago | (#5983678)

Installing Oracle 8i on a Dec Alpha Server (1998).

Processor DS20
Memory 256mb RAM
Disk 256gb

Oracle 8i (the base install) would not run because it required 512mb of RAM!!!!! That was the Installer (just for clarity).

Yeah, I am aware that this may be an extreme case of bad programming on Oracle's behalf - but let's face it, I have NEVER seen a java app run fast. Try a P2-400 with 512mb RAM for most sizeable Java apps and watch them fall into a performance hole.

Just more urban myths ;)

Java Performance (-1, Flamebait)

Anonymous Coward | more than 11 years ago | (#5983687)

Is an urban legend.

What about numerics (2, Interesting)

Phronesis (175966) | more than 11 years ago | (#5983695)

The most common thing I believe about Java is that its performance is well below FORTRAN or even C for numerically intensive work, such as linear algebra on gigabyte complex matrices.

I notice that while the article mentioned deals with a couple of nit-picky optimizations, it doesn't tell us anything useful about how to make Java rock on the numerics, which is the pace performance matters most to me. For instance, how would you write FFTW in Java?

Here's a big urban myth: (2, Funny)

Anonymous Coward | more than 11 years ago | (#5983718)

The biggest urban myth about Java:

It can be made faster by tweaking.

well..... (1)

jeramybsmith (608791) | more than 11 years ago | (#5983735)

I was hot on the java "craze" when it bloomed back around 1997. Back then the performance problem was two-fold.

Your average IT computer was less than 200mhz and had Most java that the end user saw was running as an applet and not standalone.

So their is the basic seed of the urban myth of java being slow. People who got burned by java back in the early days just want to keep repeating "java is slow" rather than try it again.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?