Slashdot Mirror
Java Urban Performance Legends
An anonymous reader writes "Programmers agonize over whether to allocate on the stack or on the heap.
Some people think garbage collection will never be as efficient as direct memory management, and others feel it is easier to clean up a mess in one big batch than to pick up individual pieces of dust throughout the day. This article pokes some holes in the oft-repeated performance myth of slow allocation in JVMs."
These java urban performance legends are rubbish - java is highly performant in a rural or urban setting.
How much time have I spent with Electric Fence and valgrind finding memory leaks in my C programs? In Java, the auto garbage collection is as good as Perl's, without that tricky "unreadable code" problem ;). And I can always tune garbage collection performance by forcing a garbage collect when I know my app's got the time, like outside of a loop or before creating more objects in storage.
--
make install -not war
JVM memory allocation isn't "SLOW". It's just pleasantly unhurried.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
JVMs are surprisingly good at figuring out things that we used to assume only the developer could know.
:) ) they weren't. The performance of the language has greatly improved while the perception of language has remained the roughly same (at least amoung the general coding community).
Yes they are. Now. 10 years ago when Java applets were being embedded in webpages (to show rippling water below a logo
Just goes to show that even if you have a great technical product you'll still need the marketdriods. Unfortunately.
http://twitter.com/onion2k
These articles keep popping up flatly stating that Java's slowness is a myth. But, no matter how many times you say it is a myth and how hard you try to create a new perception, the FACT is that people's real-world experience, no matter how anecdotal, consistently demonstrates that Java is MASSIVELY slow than similar apps in C or C++.
Java is slower. Don't even get me started on C#.
The memory allocation management routines are normally running when the JVM thinks it's best, but as a programmer it is usually possible to predict the best time when to actually take care of the housekeeping. Even if the memory management cleanup takes the same time in both cases Java has a tendency to issue them in the middle of everything. So if I as a programmer does the garbage collection at the end of a displayed page and Java does it uncontrollable in the middle of the page the latter case is more annoying to the user.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
How many JVMs can you afford to run on your system for different apps, and how can you make sure they are all the right size, the garbage collectors are in an appropriate mode that can keep up with generated garbage, etc. I can run lots of native apps, which in many cases have no need for a significant heap like Java brings into the picture in far less space than a single JVM. A JVM runs much heavier on the system, and when I run Netbeans, it is continuously on the verge of eating my 1.2 GB powerbook alive, in fact I have to frequently restart Netbeans to get memory back. It has a long way to go in real practical terms even if they have theoretical solutions to some of the problems. I am porting my server software away from Java for the same reasons. This is JDK 1.4, and I am about to try it on 1.5, but I don't think there is that much difference.
This article is actually debunking some people's reasons why Java has poor performance. It does little to debunk my actual real world experience that it *is* slow. I'm glad to see that performance has increased alot, but I remember some all (well 90% or something) Java applications, like the original JBuilder, that made me want to claw my eyeballs out when using them. Those apps and other early apps are where Java's performance issues really took hold in many people's psyche.
You so called counter argument is 6 years old... a lot of it weren't true to begin with, and a lot of things have happened since then.
In the end though, the MOST important thing is that these days, processor cycles are cheap. Programmer cycles are expensive. Therefore it makes sense to sacrifice a little bit of program performance to get more productive programmers.
Being bitter is drinking poison and hoping someone else will die
the people who keep telling me allocation in Java is slow (much slower than 10 instructions) are generally experienced Java programmers. I use Ocaml, so I'm quite aware of how fast a generational garbage collector can be (btw, on the x86 in Ocaml, allocations are only 5 simple instructions). But from all first hand reports I've heard, Java allocation is still slow. It may be faster than C++, but it's still slow.
Programmer cycles are expensive.
Not if you're counting in rupees.
I've had many professors say that Java is nowhere near as slow as it used to be, and that it was just a myth now that it is that much slower the C or another language that doesn't rely on VMs. In most applications, I guess it's actually equal enough to C to be considered as an alternative. Although it doesn't have anywhere near the rich number of libraries C/C++ works with (I'd like to see someone make a cutting edge game in Java).
In undeveloped countries, the consumer controls the market. In capitalist America, the market controls you.
First post here from my Java workstation. Take that!
But all the examples in the article aren't tested in practise. Maybe the escape analysis the author describes works as advertised. But without actually testing and analysing real code produced and without actual benchmarks the article doesn't proof a thing
The author is giving you a high-level, greatly edited view of some of the major optimization techniques in use today. The original academic/technical papers on which that is based demonstrate/measure their techniques on various benchmarks.
One thing the author seems to forget is that you would at least need a fallback mechanism when a method is overridden in a subclass
This is well-known. Code-patching, on-stack replacement, pre-existence etc are used in production jits to recover from that kind of thing. This paper has a decent summary of current approaches:
1. Make it work.
2. Make it work well.
3. Make it work fast
And #3 is the most interesting... how fast is fast? In an absolute sense, sure, C/C++ will always be faster. But does the end user notice this in a webapp? NO!
I have a p3 450mhz box running Tomcat/MySql. It serves my local applications fast enough. The server can render the page much more quickly than my browser (on a p4 1.5ghz box) can render it. As a webapp, java on an old machine is plenty fast.
Java as a desktop GUI is an altogether different story, but I'm not using java on the desktop. This point is moot to me.
"Fast enough" to not be noticeable. That is the secret of #3. In a webapp, this is easily achieved in java.
The copying collector sounds really fast indeed, but I can immediately see two problems:
The first one is the need for a huge amount of memory. It would seem that the optimal way of dealing with this is restricting the amount of memory available to the application, otherwise any app can grow to the maximum size allowed by the VM, whether it needs it or not. But this sounds rather crappy to me, now every developer needs to figure out an right limit for the application.
The second is that performance is going to suck when garbage collection is performed. The slowdown could be a lot larger than a single execution of malloc/free, especially if virtual memory is taken into account. The unused half of the memory will often be quickly moved to swap by the VM, especially when the process grows to sizes in the order of hundreds of MB. Then GC will force bringing all that back to RAM, while possibly swapping the previously used half to disk. Exactly the same situation as what's described with heap allocation, but a whole lot worse.
It sounds to me that even if malloc is slower, it's a lot less inconvenient in applications like games, where something that is always slow can be taken into account, but where a sudden run of the GC could be really inconvenient.
But this is not my area of experience, so it's just what came to mind. Can anybody confirm or refute these suspicions?
Here is a paper (PostScript) from 1987 on the topic of GC being faster than manual allocation.
The author went on to make a very fast GC that set speed records.
If you are looking for factual arguments, with performance measurements and so on, just look at his work over the last few decades -- you'll see he did a lot of work in these very practical areas.
When you see how productive guys like him can be, it makes me wish that some people would just stay alive, and keep working, for a few hundred years more, instead of our typical mortal lifespans.
http://www.thebricktestament.com/the_law/when_to_
Then use Delphi, or better yet, C#. (or even Python and a few other choices)
Faster productivity, less bugs, no ram guzzling 5 minute startup. Java isn't the only language that reduces development time, it's just the only one (besides VB) that makes you sacrifice big things to get it.
A *good* C++ programmer will probably write code that outperforms the equivalent in Java. A *good* C+ programmer will remember to deallocate all of his objects to prevent memory leaks. A *good* C++ programmer will copy his strings correctly to prevent buffer overflow exploits.
If you have been involved in developmnent for any reasonable amount of time or worked on projects of reasonable size, you know that *good* programmers are hard to come by. When you add the real world to the picture you find that simple things like garbage collection and a virtual machine can make a mediocre java programmer outperform a mediocre C++ programmer.
If schools actually learned to produce good programmers, and HR departments learned how to identify them, and job interviews verified them, we wouldn't be having this discussion.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
Programmer cycles are expensive.
Indeed. It might be worth (pardon my pun) reiterating what those cycles really are, in regard to application performance.
In all languages I know of, you get some library functions ready-made, and you need to code some stuff yourself.
Most performance problems occur in the code you made yourself.
In my experience, you get most bang for buck when you are able to efficiently allocate your programmer time to a) program a functionally complete draft version, b) optimize those parts which need optimization and c) maintain the program, in a manner which is BALANCED, but biased towards maintenance.
De facto, you get better balance between those things, and most bang for buck, using languages such as Java, as opposed to languages such as C++, because (say) Java offers a pretty coherent conceptual framework (class libraries) for creating your draft in a maintainable way, provides default access to excellent non-invasive performance measurement tools such as YourKit and JProfiler which let you objectively find out where you need to do performance work.
This means you can do only the optimization work that is necessary, and create optimized packages which extend the default class library interfaces which means that generally maintenance programmers don't have to put nearly as much work into figuring out how the optimizations affect the draft work.
It's not perfect, but it gets you more bang for buck, which is what matters to you when you manage resources.
Not the default developer perspective, I know.
Really? Can provide a few REAL world examples? Can you name one? Personally, I'm running Azureus and Netbeans right now, and they're not perceptably different from C++ desktop applications like KDevelop or OpenOffice.
The article's main point is that Java's memory allocation is faster than malloc, and it's garbage collection is better than cumulative free's.
However, thats not the problem. All memory in a Java program has to be allocated dynamically. Other languages offer static memory alternatives. Static memory use will be more efficient in many cases.
The my language is faster than yours argument is inherently stupid. There is no "best" language. You need to use the right tool for the right job.
--Barry
Simply put there may be fast efficient tiny java programs out there but I don't see them. I don't really care about how garbage is collected. All I care is that a simple editor gobbles up memory like it was some kind of FPS. Sure I love the fact that I can use the same editor with the same extensions (to a point) on my home linux machines and work evil OS machines BUT it comes at a price and that is a lot of memory.
Perhaps Sun has indeed improved java massivly over those horribly slow and crashing java applets we had a few years ago that were so going to take over the net by storm. Perhaps all the problems are just due to certain public java programs being badly written.
It doesn't matter, java is slow, c is fast. Instead of having written this article perhaps the author should have examined some common java memory hog programs and analyzed wether the fault lies with java OR the coding in question OR and this is an option few consider, that JAVA apps and C apps are often compared like apple and oranges. Azureus vs Bittorrent (a tiny and far simpler app) Eclipse vs VI etc etc.
A lot of languages deal with mis-reprensatation. I don't exactly feel sorry for the bad rep that java has as many java fanboys happily spread un-truths themselves. Like java vs PHP vs ASP for web development. Judging from my own experiences all this is just one giant "Your mom is so fat ...." competition.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
I think automatic garbage collection is great, but _my_ problems with Java's memory allocator have little to do with performance. Rather, it sucks so hard at dealing with out-of-memory conditions.
Why would you ever run out of memory? If you're on a microcomputer, you tend to have an arbitrary limit anyway. The JDK default is 64MB max heap. This is to prevent runaways, but setting the heap size to some arbitrarily high number has really awful performance characteristics -- god help you if you set the number higher than the amount of RAM you have available, or applications that want to share the machine. There's a whole other rant about how stupid automatic garbage collection is on a timeshared environment (like a server), but it's not the point I want to make.
The point I want to make: since Java is supposed to run everywhere, you really can find environments where you only have 1 or 2MB of heap to play with. Having constrained resources is nothing new to programmers, they've been dealing with it forever. But Java's allocator combined with constrained resources leaves you with very little wiggle room.
If you've ever developed a Java applicatoin that manages an in-core cache you might have experienced how fucked you are when you get around to the logic of cache expiration. Ideally you can keep cache forever, as long as a) you know it's not stale, and b) you don't need the memory for something better. A is not a problem in Java, but setting up a system to facilitate B is actually really hard. In C/C++ you can wrap malloc() so that if it fails, you can start dumping cache until it succeeds. The solution is elegant, dare I say beautiful.
In Java this is totally impossible. When you run out of memory the garbage collector is tripped, and if it can't free anything up it generates an OOM exception. You can't realistically catch these exceptions -- they can bubble up from anywhere at any time. The only place you can catch them is at the top of your program loop and the only good it does there is let you say "OUT OF MEMORY" in a user friendly way before exiting the application -- assuming you have the resources left to even say that of course.
So how does this effect your cache model? Well, you end up having to guess at how much cache to maintain. Guess too high and your application breaks when it's run in a low memory environment. Guess too low and you're not caching enough, the user experience suffers when it has no reason to. The above scenario is just one example.
Essentially, the problem is one of prioritized memory. Java gives you no usable way of saying memory allocated for purpose X is fine as long as purpose Y is not short. Designers and apologists can make excuses for why Java doesn't support this and maybe provide a good reason, but those reasons hardly qualify Java as a general purpose programming language.
Goto also.
Sun is introducing shared memory in the new VM that should alleviate this somewhat.
The idea is that the majority of the "fatness" comes from the libaries. If you only have to load the core libraries once, and each VM can use them then additional VMs won't add so much overhead.
If this works, I'm wondering, will we get side-effects from the over-abuse of static member variables.
----- If communism is a system where the government owns business, what do you call a system where business owns govern
C# and VB.NET are almost identical in features. What do you "sacrifice" that is really important? The .NET framework is still there. C# is just java like syntax for .NET. Its not 100% better as its billed by microsoft and consultants. I agree vb6 sucked.
.NET app startup time is slower than running a program written in another language as well. Try running the ati control panel (.net version). Now that is slow. Limewire loads faster and its a java app.
The java vm startup time is a problem for client apps, but server side its not a big deal. Running tomcat with servlets, jsp and the like is very fast.
MidnightBSD: The BSD for Everyone
The typical home machine these days is still sub-ghz, and Java performs so poorly as to be unusable on such machines.
I am trolling
OP's comment is based on the fact that Java is usually deployed on those big iron Sun boxes (8-way minimum, 16-way, 32-way etc. with 32Gb RAM etc. - you get the picture.) Any darn thing runs reasonably fast on these machines. And when things execute in-memory and are JIT'ed there is no reason to believe Java code will execute slower than say C/C++ code. Plus lots of design patterns have grown to make up where Java performance sucks - Use huge thread pools to avoid creating threads on demand, cache as much as you can, pool objects to avoid doing new on big objects etc. Java/J2EE makes it possible to write robust server side applications quickly without having to deal with low level details. People pay a big price for this by having to buy those big boxes on the server side. It could be argued that smart C/C++ programmers can build something more reliable/scalable with less resources - but matter of the fact is that world is full of lazy "high-level" "abstract" "mediocre" programmers. Destop is a different matter altogether - people still have machines with mere 256Mb RAM with one pale CPU - C/C++ rocks there. Java sucks badly on the desktop - Graphics/Drawing is slow, startup time is horrible, simple apps can require boat load of memory and on top of this the UI looks nasty. Just a data point - Microsoft's VC# IDE requires 29Mb - it's written in C/C++ and embeds the C# VM. Netbeans and Eclipse - last I checked they needed atleast 100Mb!
I haven't done anything with java in the last 5 years.
...BY HAND!! IT WILL NOT COMPILE ELSEWAY.
*everybody.screem("w00t!");*
I can understand the discussion about memory allocation is legitimate.
*everybody.agree();*
Now, saying this would not be the case anymore, so hence java is fast now, would be false.
*everybody.status = iritated;*
Writing jevecode does make yu handle a lot of errors...
*everybody.ask("is this not good?");*
*some.ask("is this not good?");*
Maybe there is a loss of speed for handling all those errors as well.
*FirstHalfOfCoders.grab(stone);*
C coders don't check for every possible error.
*SecondHalfOfCoders.grab(stone);*
Maybe, sometimes, it is ok for a programmer, if from that code, there could
be errors. While on the other side you buy speed with insecurity.
*FirstHalfOfCoders.throw(stone);*
*SecondHalfOfCoders.throw(stone);*
*me.troll();*
AND BY THE WAY; I LOVE THE "GOTO" STATEMENT!
*me.run(away);*
Bjarne Stroustrup : why so many people use "C++" just as "C" ?
Dennis Ritchie : because you named the language "C++", not "++C"
I have been doing Java programming for several years now and ported many C/C++ applications to Java, mostly server side apps and I'd say roughly 85% of the time the Java apps outperformed the originals, sometimes by an order of magnitude. Now these were more redesigns than straight ports and the performance gains were not because Java was any better from a performance standpoint, but because design is more of a factor in speed than the language used, especially for larger applications. Usually when I find big performance hurdles that are hard for me to overcome, I find I would have same issues in most languages, so finding a better design is usually the solution. If you are writing small - medium apps or mostly GUI apps then I might have reservations about Java, but for larger apps Java is a good choice.
The typical home machine these days is still sub-ghz, and Java performs so poorly as to be unusable on such machines.
A typical mobile phone is sub-ghz too, and there is plenty of J2ME software running on them...
Java rocks on limited devices AND as server software. It is only on the desktop it isn't a big hit. Yet.
Being bitter is drinking poison and hoping someone else will die
I've never believed that Java's garbage collection is the root cause for its slowness. I do believe that Java's GC is the cause for its random (and more notably, its inconveniently timed) stutters.
I think the more general Java slowness comes from the obfuscation of efficiency. In C for instance, ugly code correlated with inefficient code. This is no longer the case for object-oriented programming in general, and it is possibly worst correlated in Java.
The example in the article provides a starting point for what I'm saying. It's based on the algorithm for a point in some Cartesian graphics system:
The Component.getDistanceFrom() algorithm is considered "good OO style." By using bad style, though, you can break the pretty encapsulation -- and make "bad OO style" -- but get a performance gain:
Both code blocks require the math (two subtracts, two multiplies, an add, and a square root) but the original block (unoptimized) also requires the allocation of the Point object and the two memory copies to store the (x,y) location.
This is a trivial example, but my point is that in a complex Java project, readable and elegant code bears no correlation to fast and efficient code. I believe this is why Java is slow.
--- Jason Olshefsky
Karma: Poser (mostly affected by adding this line long after everyone else did)
Unfortunately, programs such as Azureus, which run piggishly slow on a 1.2GHz laptop do nothing to dispell these 'performance myths'.
The common code path for new Object() in HotSpot 1.4.2 and later is approximately 10 machine instructions (data provided by Sun; see Resources), whereas the best performing malloc implementations in C require on average between 60 and 100 instructions per call (Detlefs, et. al.; see Resources).
Wow, that's really shocking. Until you actually look at the Detlef paper and realize that it was published in 1994, 11 years ago!! Who knows, maybe things have improved a bit in 11 years. The author certainly thinks Java is getting better; maybe it's possible that C/C++ compilers have improved as well.
Here's a link in case you ever get the urge to write some Java code.
Five minutes startup times is also a myth. Most small to medium size Java application I have start in under a minute. Of course the more dependencies and the larger the application the more time it will take. I suppose we could compare this to you average game, written in C/C++, which can take over two minutes before you are ready to go.
For an enterprise application, running as a server, start-up time is not really an issue. What does matter is ho well it does once it is running.
Jumpstart the tartan drive.
I have never felt the last bit of anxiety when choosing to "allocate" an object on the stack. I do not even call this an allocation, I just use a local variable that happens to be an object.
I only allocate an object on the heap when I know this object needs to be exported from the function -- which is something I'd better be aware of by design.
Stack-allocation is an easy, default, way of life in C++. It is even a key idiom for managing non-memory resources (RAII).
When programming in C or Java, what makes me agonize is to manually ensure that (non-memory) resources are released properly and in a timely fashin (files, locks, communication ports, etc). try...finally blocks, anyone ?
While I'm sure you can point to a Java program which takes 5 minutes to start, these are the exception in the Java world, not the rule. In fact, the JVM takes seconds (a small number of seconds, less than 5) on all of my systems, including P3's as well as older AMD's. It takes less than 2s on my Athlon 4800+. I can go from Tomcat not running to it being completely started up and serving requests in 4s on my PC, and 11s on my older G5. My IDE, which is extremely feature-rich, takes ~90s to get to where I can start typing code from a completely cold start, in a middling (30K LOC) project. That includes a ton of lib caching and such, so that it can do incremental compilation in real time. It takes 16s to restart once that caching is done.
.Net in memory for your C# program, and that's no small chunk of RAM. The first time you start up a .Net app of any size you're going to be waiting for it to draw for just as long. And it's no better for scripts, just how fast does Mono start up anyway?
As far as guzzling RAM goes, all programs these days guzzle RAM, and they're right to do so, because RAM is cheap. This is not unique to Java, the IDE I mentioned uses 56M once it's really going, surely not an unreasonable amount of memory for such a complex app. Java is still not the best choice for small scripts, Python would be better if your program is going to be mostly startup/shutdown time. C# is no better than Java though. Don't forget you need most of
A typical mobile phone is sub-ghz too, and there is plenty of J2ME software running on them...
Java rocks on limited devices AND as server software. It is only on the desktop it isn't a big hit. Yet.
Ha! That's a good one. I work with mobile phones, though I personally don't use J2ME. All the programmers I work with do though (the carrier chooses). J2ME really sucks.
The J2ME spec has a lot of fuzzy places and "MAY"s. You will find the full spectrum of possibilities in such places. There are also many imlpementations that blatently fail to meet the spec. (I've heard that boolean operators *sometimes* short-circuit, but I'm not sure I believe that.)
Fixed point math is common for these small systems. In Java, you end up looking like Lisp. FP.sqrt(FP.add(FP.mul(a,a),FP.mul(b,b))); Yuck. In C++, you look like C++. sqrt(a*a+b*b);
Then there's the jar size limits. Some phones only give you 64k to work with. And on top of that, each new class and function adds to the size of your app. So if you want to do some nice modular OO design, forget it. With C++, no problem. There are no size limits (aside from usable memory) and extra classes/functions are nearly free. Again, in C++ you can reuse loops and wrapper code to shrink code size, passing in a function pointer for the inner part. In Java? The extra overhead for the class you'd need to work that way cancel out the benefit.
Garbage collectors typically used in J2ME are way behind server and client versions. And when they don't work well enough automatically, system.gc() might force a garbage collection. Maybe, if you're lucky and the manufacturer felt like implementing it.
J2ME phones are almost universally one notch slower than the BREW equivalent. Some of the Samsung phones have poor performance under BREW, but are simple dreadful with J2ME. It's the difference between getting 4-5 frames per second and getting 1-2 seconds per frame. And if you're doing funky stuff with bitmaps that the phone has a slow implementation for, in C++ you can walk around the implementation and do it yourself. In Java, you're screwed.
J2ME is a joke.
Garbage collection is nice. It does its job and it does that job well.
But garbage collection only helps you manage one sort of resource. In C++, the RAII techniques that help you manage memory are good for every resource, from file handlers to database connections. Resource management in Java is not so nice. Often it is quite a hassle.
Also, if you really want the benefit of garbage collection in C++, simply compile your program using something like the Boehm Garbage Collector.
Which is the point.
Systems programmers write systems code. There is no one size fits all. There is no silver bullet. Comparing out-of-the-box C/C++ to out-of-the-box Java is a non-starter in my opinion because I've never used out-of-the-box C/C++ for large scale performance applications. What Google did in writing custom systems software is something that cannot happen with Java and is the accepted practice for C/C++.
Java programmers write applications in a "one-size-fits-all" performance environment. Comparing Java to C/C++ is like comparing apples to oranges.
Serious C/C++ systems programmers write their own malloc and systems software.
Most memory leaks I have seen in C come from the simple fact that it is not possible to allocate space on the previous stack frame. If the runtime included a mechanism for moving an allocation to the caller's stack frame (which would be trivial to implement) then most of them would go away. One other work around for this which I have seen is to have separate call and data stacks. Rather than calling malloc, you call a function which gives you a block of RAM on the top of the data stack. The data stack can be pushed and popped independently of the call stack, so a function that needs to return an arbitrary amount of data simply allocates it on the data stack, and returns a pointer to it. The pointer remains valid until the next time the data stack is popped.
I am TheRaven on Soylent News
> Delphi is Windows only and owned by a company with a very questionable future (forget about Kylix). C# is > basically Windows only as well.
The Borland implementation of Delphi is, but others aren't:
http://lazarus.freepascal.org/
Oh yeah! Now that you mention it, it really is funny! You see, the article talks about how Java is not as slow as is generally believed, but then the grandparent says that he posted the message using Java! That's not funny as such, but it is when you consider that it's supposedly the first post! And it's funny to think that he might have actually been the first to post the message, but since he was using Java, its slowness caused the message to be actually posted waaay late!
Too funny!
See, that right there is a huge chunk of the whole problem. If programmers weren't being lazy and arrogant jerks and assuming that nobody cares about how poorly designed and coded their algorithms are, or how blatently horrible their memory usage is, we would have a lot fewer problems.
I don't care that Java will get there at some point, or that it's better now. I care about whether it actually works right, and right now it does not. It does have too long a startup, most of the UI toolkits are horribly slow, it does not follow native platform UI conventions, and it is just not as nice to use a Java app as it is an equally well written native app. It does take far too memory, especially compared to other languages. Even the cross-platform nature of the code is largely a lie. Different JREs don't support the same things, and many platforms lack a JRE. There are massive differences between the various editions of Java so as to make it useless to try to write something across them. Your Java app written against "Vendor X Version Y Edition Z JRE" should work fine on any other platform with the same version of "Vendor X Version Y Edition Z JRE". That's all you can safely say without a good amount more testing.
However, most of all, my CPU time and RAM might be cheap, but they are abused every time I use an application written in that mindset. I have memory needlessly abused, and CPU time needlessly wasted every time I run some poorly coded program. That means that I lose time and productivity every time I run your poorly written app. That attitude pisses me off, why we should all squander our system resources so that a few lazy programmers can write some app a little faster and with less effort, rather than doing their job right.
Programmer cycles are a lot cheaper than making thousands of people upgrade their hardware. I imagine those programmer cycles are a few orders of magnitude cheaper.
Startup of Java seems a little slower than CLR but not markedly slower. Mono's startup is hardly a speed demon either. In all, I think most of the hype around the CLR is just that - hype. The CLR is a lot nicer virtual machine, and C# is as close to C++ / Java that I couldn't care which language I'm writing to, but the performance differences are IMHO neglible.
As an example of how fast Java is, I have written a poker simulator which plays 1000 games from a deck of cards which is shuffled 1000 times for each game. The hands from each game are then sorted, and scored. It's very Vector and LinkedList intensive and each loop probably sees a dozen or so temporary Vectors or arrays used during comparison - i.e. 1,000,000 iterations with many more nested within. It takes just over a second on my 1.8 Ghz PC.
As far as I'm concerned, that's plenty fast. I reckon I could probably halve the time if I bothered to replace all the vectors with fixed arrays.
It would be hard to compare Delphi (as in traditional Delphi) to either C# or Java since it is a compiled language. I don't know what Borland are doing with it these days so I wouldn't be surprised if it's gone the CLR route too.
No, it's not really fixed. It's just syntax candy that lets the developer see strongly typed primitives, even though in the underlying JVM, you'll notice that it's still just a list of boxed Objects, thus losing performance and memory benefits with the inducing of boxing and unboxing of each element in the list. Contrast this with the .NET or Mono runtimes, where the runtime actually creates code for storing primitive types, thus gaining a performance and memory benefit.
Tech, life, family, faith: Give me a visit
Unless, like me, you're the guy who's writing that library that everyone else depends on, in which case the two are the same thing for practical purposes. In that case, trust me, you still use something like C or C++.
Here are a few reasons why:
Any of those in isolation is game, set and match against the arguments in the article. Put together, you get the same picture most of us have painted all along: Java's performance is adequate for non-critical tasks, but it's nowhere near the top of the pile when it really matters.
BTW, in case anyone's wondering: yes, I do work on widely-used, performance-sensitive mathematical library for a living, and yes, as it happens I really have spent the last few weeks researching ways to increase the performance of that library even further.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
While I agree that in theory, and in labratory conditions, Java is just as fast (sometimes faster) than C/C++, in practice it doesn't usually end up that way.
.NET available instead.
The way normal people write code, and the libraries and functions that normal people use, java is slow as snot. I don't care why that is, it just is, and it makes me steer away from Java client applications if there is something that is native or
Real world results are different from labratory ones as far as Java is concerned in my book. And that's just my experience.
If you need web hosting, you could do worse than here
As soon as you go to a website and seed the dreaded .jsp extension, you know you're in for a wait.
All the websites that use Java are just ridiculously slow. Name one that isn't.
Could you imagine Google running Java and some JVM?
Summary: "If JVMs were smart, garbage collection would be fast."
Reality: "JVMs are mostly very stupid, and you can never be sure what JVM your users are going to use, so in the real world of deployed applications garbage collection performance--and Java performance generally--is a nightmare."
I am so tired of GC advocates talking smugly about theoretical scenarios. Who cares?. When I can run a Java app on an arbitrary JVM and not have it come to a grinding halt every once in a while as the garbage collector runs--or worse yet bring the machine to a grinding halt because the garbage collector never runs--only then will GC will be useful.
The weasel-words in the article are worthy of a PHB: "the garbage collection approach tends to deal with memory management in large batches" Translation: "I wish GC dealt with memory management in large chunks, but it doesn't, so I can't in all honesty say it does, but I can imagine a theoretical scenario where it does, so I'll talk about that theoretical scenario that I wish was real instead of what is actually real."
This is not to say that there aren't one or two decent JVMs out there that have decent GC performance. But having managed a large team that deployed a very powerful Java data analysis and visualization application, and having done work in the code myself, and having had to deal with user's real-world performance issues and having seen the incredible hoops my team had to go through to get decent performance, I can honestly say that up until last year, at least, Java was Not There with regard to GC and performance.
The most telling proof: my team did such a good job and our app was so fast that many users didn't believe it was written in Java. It was users making that judgement, not developers. Users whose only exposure to Java was as users, and whose empirical observation of the language was that it resulted in extremely slow apps. They didn't observe that it was theoretically possible to write slow apps. They observed that it was really, really easy to write slow apps, in the same way it's really easy to write apps that fall over in C++, despite the fact that theoretically you can write C++ apps that never leak or crash due to developers screwing up memory.
Every language has its strengths. Java is a good, robust language that is safe to put into the hands of junior developers to do things that would take a senior developer to do in C++. But its poor performance isn't a myth, nor is its tendency to hog system resources due to poor GC. Those are emprical facts, and this article introduces no actual data to demonstrate otherwise.
Blasphemy is a human right. Blasphemophobia kills.
I believe that, directly or indirectly, an unjustifide emphasis on execution speed is the one of the biggest causes
of the failure of software projects. The problems usually begin with the choice of
implementation languages. Programming languages should
be chosen for the ease and cost effectiveness with which they can be used accurately and reliably generate
a correct and maintainable application that satisfies the customer.
In my experience selecting a language because it is "faster" than another language
before it is even known what the speed issue is for an application is just a costly mistake.
For speed critical parts of an application an experienced C++ programmer might be a without-which.
A tool like JWrapper can be used to connect a Java application to an optimized C++ library.
Speed requirements should usually be dealt with towards
the end of the development. Most of the execution time is usually spent in a small fraction of the code.
Only that portion of the code should be optimized because optimizations can be costly to derive and implement,
costly to maintain, and more difficult to verify.
In the interest of peacefull coexistence we might all agree that:
1. Java is sometimes too slow
2. C and C++ programs sometimes have memory leaks.
3. Writing efficient, reuseable, object oriented programs in C++ can be an extremely subtle business and,
as a result, good and efficient C++ programmers are harder to find.
Nope, not compared to Python or Ruby (which yield codes rougly 5 times smaller in a quarter of the production time), not compared to Lisp for an ol'timer, not even compared to C# (by a quite small margin though, but C# has a lot of very nice feature Java doesn't have).
Writing Java is faster than writing C/C++ indeed, but not "very fast", not without any referential to compare to, because dev-time wise Java gets it's ass handed to it by much more agile languages.
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
A quick web search turns up several surveys with lots of benchmarks,
http://java.sys-con.com/read/45250.htmr k.html
http://www.idiom.com/~zilla/Computer/javaCbenchma
This is about as much of a myth as the myth of the earth traveling around the sun. There is a lot more to allocating memory than this article lets on. Psuedocode will always be slower than machine code no matter how you slice it. You can do various tricks to make it seem faster by instruction count at certain things but in the end those same things can be applied to compiled code like c/c++. Most people can accept that as fact and move on using Java where it seems appropriate. Make all the excuses and extraordinary claims you wan tint the end Java is just plain old FAT n slow, anyone in any programming course who has used java can tell you that.
Oh and it is hard to test out his little theory on the free malloc in C++ because you can't do the same thing in Java. You can try but it will get around to the free part when it gets good and ready and may not attempt the malloc until you use the memory.
I never said it was. I was just responding to the point that GC is unsuitable for hard realtime systems (which is false). It's simply another method of heap management, and can be implemented with realtime requirements in mind. I also never said that Java or any other current garbage-collected language is actually suitable for this. I'm just saying that there is nothing theoretically preventing these features from being used in realtime systems. Likely to do that we will want languages (or new features for existing languages) with more expressive means of specifying the realtime requirements in a high level way.
(I do think that there are significant advantages to having a GOOD GC system that a lot of people ignore. They are simply another type of abstraction, which can be a gain when you have no need to worry about memory management implementation issues. Why should we reinvent the wheel over and over again when we can have the language designer develop a very sophisticated means of handling this automatically? There are times (such as in realtime situations) where you may want to get at the lower-level details, and that's fine. But in 90% of software written, this is absolutely unnecessary and leads to tons of bugs which could be avoided by using a higher level language.)
Ermm, one question: is your poker simulator multi-threaded? If not, try ArrayLists in place of your Vectors in the Java code. Vectors are internally synchronized, which will hit you for a pretty big performance penalty.
Sorry, Vector over-use is one of my pet peeves. It's silly little programming goofs like this that make our programs slow, and give the anti-Java trolls more ammo.
"In a 32-bit world, you're a 2-bit user. You've got your own newsgroup, alt.total.loser." -Weird Al
I believe that this battle can be summed up in the battle of Java vs. PHP. Here we have a fully OO VM based language that has been widely deployed on both Unix and Solaris, vs. a (mostly) UNIX only scripting language turned web programming language with lots of web-specific features. I have developed large solutions in both languages, and it really comes down to: PHP rocks for quick-and-dirth websites. Put a PHP next to a Java guy to develop a basic ecommerce or content mgmt website, and PHP will TOAST that guy. Now required six-sigma reliability, 100+ hits per second, redundant servers w/ clustering, the ability to connect to multiple corporate database from different manufacturers, and other high-end enterprise features, and Java wins hands down. Not to mention of the security of PHP vs. the security of Java - PHP is "wide open" in many ways. USE a big hammer for a big nail, and a small hammer for a small nail. Java ran WebMD (many thousand hits per second, all data driven) with an early version of Java 1.1. - yes, we need to clean up the socket code some w/ SUN, but it worked, and it worked very well. The future looks to me .NET - Microsoft was brilliant - a well defined software app network architecture what is language agnostic. This time in a few years there will be many Java programmers writing web-service code behind the .net standard.
Thanks for reading my stream-of-consciousness.
Horns are really just a broken halo.
OK, I'll enlighten you. Well, not you, who stubbornly refuse to be enlightened, but somebody else who may be reading.
With a stack or with copying GC, you do allocation by doing a simple add (or subtract) and a check for overflow. On many architectures the check can be implemented using dynamic address translation (virtual memory) capability of the hardware.
With a stack you must pop the stack when you're done. Another simple arithmetic operation. With garbage collection, you do nothing at this time. Running score: stack 2 operations (push,pop); GC 1 operation (allocate).
But with GC you eventuallly run out of space so you copy all the in-use storage. Here's a formula:
That is, the total number of pieces of in-use storage is strictly less (and in practice substantially less) that the number of allocations. Running score: stack 2 operations * #allocations; GC 1 operation * #allocations + 1 operation * (substantially less than #allocations).That is, for each allocation a stack regimen does a push and a pop, and GC does an allocation and some fraction (substantially less than 1) of a copy.
While I'm at it I'll point out that there are many cases in which procedures may be implemented without using dynamic allocation - stack or GC-ed - at all . Your allusion to that mystical compiler that works some sort of stack magic "for free" is simply wrong.
I'll try one more time. There is no rule that says the compiler has to translate function calls and return into assembly-language (stack-based) calls and returns. There is a technique, known as continuation passing, in which returns are never used. You may educate yourself by acquiring Appel's book "Compiling with continuations" or by reading Guy Steele's master's thesis or, indeed, by reading the references already given.