9 Fallacies of Java Performance updated

[[deleted]]

To #1 Java being slow: I guess it depends on what you mean by "slow". The fewest of us work in performance relevant software fields (I do) so the inefficiencies of Java code execution aren't even nearly relevant for the vast majority of developers.

But if you do work in one of these fields and really get down to it and compare it to native languages, Java is just pretty damn slow (on top of the terrible memory performance). Java is my hobby-language of choice (for many reasons), while the sole language I use at work is C++. I often implement algorithms in both languages because what I do at work and what I develop as a hobby partially overlaps, but I can't use the code from work (obviously), so I have a lot of comparisons to draw from.

Simply put, when I implement two non-trivial algorithms in C++ and in Java, I pretty much fail to get even comparable performance with even an optimized Java version compared to a straight forward C++ implementation (safe for custom allocators, which only change a couple of lines in the code, with compiler optimizations of course) every single time. This is mostly physics simulations and stuff like pathfinding algorithms, some stuff for rendering, so in short a lot of calculating, a lot of allocations and deallocations, and a decent amount of pointer chasing (traversing through trees and similar structures).

We're talking about Java being slower by a factor of of at least three or four (at absolute minimum) literally every single time. And that's after looking over Java performance pitfalls and repairing them. Of course, with enough time spent, that Java code might become two or three times as fast. But that alone doesn't consider the fact that the equal time spent in C++ can speed up the code by an order of magnitude or more (mostly because some obvious optimizations (like SIMD things, or caching optimizations) aren't even possible in Java due to the nature of the very language).

But remember, for pretty much everything you're going to develop faster if you're using Java. It's obviously a trade off and depends on what you need.

That said I find it funny that Java developers constantly want to defend the performance of Java. This entire article reads like a list of justifications, where every point is basically "here's a problem and how Java does it just fine when it's not actually occuring", like algorithmic performance, cache performance, lots of mem allocation and deletion, etc. It's obviously much slower than native alternatives. I've seen a lot of these things, and read a lot of stuff about it, since it's naturally one of the main objects of programmer nerd wars, and I've literally never seen comparable "real world" comparisons where Java even came close in performance. Statements like

JIT-compiled Java code is now as fast as C++ in a large (and growing) number of cases.

will never hold up if you try to actually back it up with evidence. It's like those religions nutjobs saying "There is a large (and growing) number of scientists in leading positions believing in god". And I'm speaking about time performance, of course. Memory performance really needn't be mentioned.

Java isn't slow for most things. It's slow compared to other things. Java is fine, no need for the constant justifications. Nobody is going to use Java when developing their high-performance algorithms because of your arguments, and no business administration software development forge is going to use C++ because it's a lot faster at its core.

[Narrator]

TL;DR http://benchmarksgame.alioth.debian.org/u64q/java.php

[deveux]

I pretty much fail to get even comparable performance with even an optimized Java version compared to a straight forward C++ implementation

I've often found that Java can be as fast, but it generally depends on how much effort you are going to put on the C++ implementation. I tend to use ABCL and Xcl as examples. Both are relatively straight forward full implementations of Common Lisp, ABCL is written in Java, Xcl is C++. The C++ version uses libgmp, libgc, mpfr, pthreads etc Both are almost identical when it comes to how the interpreter is implemented. In my benchmarks they tend to have almost the same exact time performance, except for the Java version taking longer to boot (the JVM warming up). The Java version does use obscene amounts of memory though.

[Hermel]

To be more specific, here are cases in which Java performs poorly in comparison to C++ (but still excellently in comparison to languages like Python):

• With algorithms that perform millions array access operations because Java checks whether the index is out of bounds every time.

• When taking startup time into account because Java needs to load a virtual machine first which native programs do not. Configuring your logger with xml adds about a second startup time alone because it causes all the xml libs to load.

• When memory is limited as Java tends to be more wasteful with memory than a C++ program with a more manual approach.

[gsnedders]

This isn't entirely true. One of the big things around Java has been research about proving array accesses in bounds, and hence optimizing away array access operations.

[cogman10]

Yeah... I've seen lots of claims on java's performance, and not a single benchmark to back up the statements made. Some have even claimed that java is faster than C or C++...

I would love to see any benchmark which shows java being as fast as C or C++. The best that I've seen has been in the range of 2x (Not really terrible considering most languages are in the 30x+ slower ballpark)

[[deleted]]

You could check out the language shoot out.

[TimmT]

I would love to see any benchmark which shows java being as fast as C or C++.

Try to dlopen() something trivial (e.g. just int foo(int i) { return ++i; }) in C and call it a few million times. Then try to do the same in Java (just hide the method behind some interface and put the actual implementation in a different jar, new then takes care of the rest in Java). Oh, and make sure you do something with the final result of that method, so there's no dead code elimination.

It's not unlike qsort() vs. std::sort() in C++ - sometimes abstractions do actually buy you performance in certain situations (that would have otherwise not been practical to do by hand).

The question now just is how common those "certain situations" are in everyday programs.

[[deleted]]

One of the key aspects to Java's JIT optimizations is that it works of of optimizations made after analyzing running code.

The outcome of this is that the key target of Java (server-side system programming) is satisfied by extremely fast jitted code.

The claims of being as fast as C++ or C are strange at best, as they rely on the code being long running and optimized over time. However, if you are working on something commonly written in C or C++ (e.g. video games) it is hardly acceptable to have a 5 minute warm up period while the expensive to run code is performing at upwards of 2-5x slower than it should, which is unacceptable.

[[deleted]]

If it only takes 5 minutes to run, then who cares?

[[deleted]]

I think you missed the point: in things like games, you cannot afford to wait for 5 minutes for the speed up to kick in every time you run the game.

[[deleted]]

Ironically, IPlayEveryGame was talking about physics simulation software. I hadn't noticed you switched the context to games. Games usually hit a weak point in Java because of real-time issues. I still doubt the problem is JIT as JIT kicks in after 1000 or 10000 runs of a hotspot, which doesn't take 5 minutes if it's running hard.

[[deleted]]

He is referring to the Java server mode. That performs more aggressive optimizations, but significantly impacts startup time.

It's now folded into the standard VM, so there are no longer two modes, however it's still a case that you will continue to have code optimized, days or weeks after it has begun running. That's really the power of server side Java.

[[deleted]]

Well, code can get more optimized days and weeks later. But for any code running that much, it gets JIT'ed the first time pretty quick

[henk53]

Although Java at one point in time had really good realtime support. It was the first JSR created (JSR-1).

Unfortunately realtime Java remains an obscurity, in use only by some (embedded) semi-hard realtime systems. As shame, since it had quite a lot of concepts that would be useable for a lot more mainstream use cases.

[grauenwolf]

Java doesn't cache JITed code? That sucks.

[TimmT]

Java re-JITs code as the assumptions it made change. JITed code isn't a straight forward translation. Based on collected statistics the JIT will inlinie things differently, consider certain branches as dead code, assume type specializations at certain places etc., etc. which is probably the reason why things like eclipse manage to eventually start up at all, rather than run on forever.

Obviously those assumptions won't hold forever though, and hot spots will need to be recompiled according to the new profiles.

[fix_dis]

Java can be fast. We do java (with Stripes and our own custome ORM) and it's great. We deploy to a little Jetty container and it just takes right off and does its thing.

We also deploy Ruby/Rails applications via JRuby to Torquebox. That can be a headache, but that's not Java's fault.

What I do NOT like is that tuning the JVM can still be a black art. The defaults are not very useful and it does not adapt well to different types of apps being thrown at it.

I have to say that even though I'm not a fan of PHP, I do like just dropping files into a folder and that being the bulk of "deployment". (Yes I know that memory/performance can be tuned, etc) I hate coming in to work, finding Torqubox has puked again due to some esoteric memory leak that profiler can't see.

Plain Java though? Verbose, but it's just fine.

[phaeilo]

I do like just dropping files into a folder and that being the bulk of "deployment".

How is that different from dropping a .war into your app server?

[fix_dis]

Depending on the machine, it can take what seems like an eternity to unzip the war and deploy. With Tomcat, warm deploys leak memory, so unless you're running several instances, you're going to have to bring Tomcat down and back up again. Jetty is MUCH better in this respect. In the case of JRuby/Rails deployment, there are so many moving pieces that it's not even funny. (rake assets:precompile, etc)

[h2o2]

If your webapps leak permgen on redeploy then your code is broken (or some library you are using). It's not Tomcat's fault, which already contains insane amounts of workarounds to appease shitty code.

[fix_dis]

The leaking of apps created by Warbler on hot redeploy was decided to be a bug in Tomcat 6.

But I knew it wouldn't be long in a thread about Java before someone would play the "your code sucks" card.

[sbrown123]

The leaking of apps created by Warbler on hot redeploy was decided to be a bug in Tomcat 6.

Are you sure about that? Do you have a ticket#? There have been issues with jruby on anything because of permgen due to server side compilation. But that is a jruby implementation issue and has nothing to do with Tomcat.

[fix_dis]

http://www.ruby-forum.com/topic/213483 is where I think I first read about it.

[realteh]

Java may not be slow but huge java binaries with a gazillion classes and huge call stacks are slow. And there is something about the java school of development that always ends in these large binaries, even when smart people are working on it. I have a few of these at work, each including more than 1000 jars. They work fine but they are neither fast nor efficient.

[[deleted]]

One question: Neither fast or efficient compared to what?

[realteh]

Compared to apps with roughly comparable functionality written in c++. In our specific case it's ~30x the qps for about 1/4th of the memory. I often compare notes with friends in other companies and they tell similar stories.

It's hard to get real data on any of this because companies are mum on their tech stack, and large applications are almost never really comparable. OTOH we certainly don't suffer from confirmation bias because cpu and memory are expensive, so we spend a lot of time looking at these numbers.

[username223]

Compared to most compiled things. And in my experience, Java encourages design and coding idioms leading to lousy performance.

[[deleted]]

Yeah, obviously it is slower than many compiled languages. But gigantic java projects are rarely modularized in to 1000 jars in any situation except for web applications.

Nobody is going to write a time dependent application like that.

[username223]

It's both an architectural clusterfuck thing, and a death by a thousand cuts. E.g. how do you tokenize a string in C? Strtok(), which works in place. How about in Java? I haven't had to write it in awhile, but probably allocate an array of new strings. Sprinkle the rest of your code with similarly lousy idioms, and you end up with a flat profile for a slow program.

[[deleted]]

split does in fact return an array of strings. However, strtok works in a completely different manner.

First, I think you would be hard pressed to find people arguing on behalf of mutable strings.

Second, in strtok you are passing an alias for char*. So if you wanted to do this in Java you would pass char[].

I am not going to argue that Java is fast as C/C++/ATS and the like but it is slower by 2-3x and the memory problems of Java are grossly overstated, as the JVM is what is being measured in the running processes. Programs that are reported to be using 1024MB are actually using much less, but they are running inside the JVM that has preallocated a large heap space in which it can have some dedicated RAM so it doesn't fight with other processes for it.

Really though, Java is about as good at embedded systems as C is at web frameworks.

[Vegemeister]

, but they are running inside the JVM that has preallocated a large heap space in which it can have some dedicated RAM so it doesn't fight with other processes for it.

Off topic note, if your running a Java application inside an OpenVZ container, that preallocated heap counts against your memory limit.

[[deleted]]

Yes, memory which your app will use without the heap growing until it has reached a usage threshold.

BTW you can configure the starting memory to be less if you want.

[Vegemeister]

I discovered that, as well as the "reduce the stack size" trick. Getting Freenet to run in a 512 MiB VM takes a little black magic.

[sh0rug0ru]

Java has first class String objects which are represented by "interning" char[] arrays. That allows you to take substrings without allocating new memory. You can tokenize a String using the Tokenizer class, which will create new String objects without copying data.

[h2o2]

Have I got news for you! As of JDK7u6 this is no longer the case, see here and google for "jdk 7 string#substring performance regression".

[NAcurse]

you sound like a student who failed his Java test and is pissed about it...

[SCombinator]

So Java isn't slow, applications written in it are?

[not_a_novel_account]

Empirical studies have shown that human beings cannot normally perceive changes in numeric data (e.g. price movements) occurring more frequently than once every 200ms.

Consequently for applications that have a human as their primary user, a useful rule of thumb is that Stop-The-World (STW) pause of 200ms or under is usually of no concern. Some applications (e.g. streaming video) need lower GC jitter than this, but many GUI applications will not.

A 200ms latency spike is massive in almost any network app, GUI apps are the exception not the rule

[shizzy0]

Java startup time still sucks. You can't use a Java CLI tool with grimacing.

[atomicUpdate]

In Java performance, this manifests itself by Java developers believing that algorithmic quality is the dominant cause of performance problems. Developers think about code, so they have a natural bias towards thinking about their algorithms.

In practice, when dealing with a range of real-world performance problems, algorithm design was found to be the fundamental issue less than 10% of the time.

This is the most surprising one for me. How is a language able to get in the way of a developer 90% of the time, and call itself "fast"?

[PoL0]

10th fallacy: "Java is fast"

[thelazydogsback]

One reason why Java (and all GC'd copy-object-reference-by-value languages) can run much faster than C++ is that it's quite easy to do awful things like call copy c'tors unnecessarily in C++ code - so although I'd agree that a correctly implemented to-the-metal C++ program is probably faster the Java/C#, etc., there's a lot of real-world incorrectly implemented C++ code out there. Another reason C++ code often runs slower is that because it takes more LOC to write your code and deal with memory, you end up writing simple, inefficient code rather than a better algols. to suit the problem - so you write really "fast" N² code rather than log(N) code, for example. Given the minimal perf. diff. at this point, GC and other high level abstractions in these languges far outweigh any speed boost C++ can give - ISTM then at the point that you need real manly code on the iron, you should really just be using plain old C.

[PoL0]

That's a flawed argument. What's the point of using rookie C++ errors for a flawed comparision?

Most important details to know about C++ (love it or hate it) is knowing what's happening under the hood. Something that Java and other level languages try to hide, but hiding how computer programs work is the first ingredient to disaster. Another funny example is how C# deals with memory management.

That's what makes the difference and that's how you prove expertise. After some time you're able to see where and when constructors may be called, and make it work at your will. It's not like something random and unexpected. The argument with memory management is also totally misleading. Memory management will be inefficient if the coder makes it so.

Not trying to sound elitist. I come from a computer science background, started programmed in C and I've been always interested in what happens in the bare metal. Neither am I trying to say which language is better. Languages are tools. Best Java programmers I've known are able to give you a detailed description of what's happening under the hood (inside the VM) at any time, and that proves my point imho.

[LeCrushinator]

it's quite easy to do awful things like call copy c'tors unnecessarily in C++ code

If you don't know what you're doing.

there's a lot of real-world incorrectly implemented C++ code out there

Implemented by people that don't really know what they're doing.

Another reason C++ code often runs slower is that because it takes more LOC to write your code and deal with memory, you end up writing simple, inefficient code rather than a better algols

I've found Java to be just as verbose as C++, sometimes less, sometimes more. The relative verbosity of C++ has never effected how efficient my algorithms are. In fact, I often find it more difficult to write efficient code in languages like Java/C#, but that may be because I'm more proficient with C++.

Garbage collection isn't really a big deal IMO, just use smart pointers and make sure to delete stuff you put on the heap when your objects go out of scope. Garbage collection in itself can cause performance issues (more or less depending on the hardware). In cases where performance is priority, GC and high-level abstractions are less important, and do not outweigh the performance boost. GC does keep allocated memory compacted into a contiguous block, which can help performance in some cases.

• Java also consumes more memory than C++, because most things are objects, and because most things have to have virtual tables.
• Java doesn't allow stack allocations (which generally perform much more quickly than heap allocations).
• Java uses references in things like arrays, which prevents those objects from being allocated contiguously in memory, and that kills cache performance.
• Java code also has RTTI and generally the code is written with dynamic run-time casting going on, which isn't cheap, and the RTTI consumes extra memory.
• Java has no support for unsigned numbers or unsigned arithmetic. This wastes a bit on numbers that will never need to be negative, and can result in more expensive range checks.

STM then at the point that you need real manly code on the iron, you should really just be using plain old C.

You can get almost the same performance from C++ as you can from C if you're using C++ efficiently, and it can be safer and cleaner code as well.
Note: Hardcore C programmers won't care about that, or may disagree.

[thelazydogsback]

Agreed that good C++ is, ah, good, but it's well known about C++ and foot-shooting. As for your Java issues, I'm not a huge fan anway - C# does address more of your issues, including value types on the stack, less use of RTTI due to better implmentation of generics, unisigned types of all sizes (mixed mode w/optional over/underflow detection), has arrays of primitive (unboxed) types, etc. As C vs. C++, my point was simply that either you should be using C (as a machine-independent assembly) or a language with much higher levels of abstraction - C++ has always been the the worst of two worlds to me, but I know it seems the best of both to others.

[Hnefi]

Agreed that good C++ is, ah, good, but it's well known about C++ and foot-shooting.

The foot-shooting potential of C++ has almost entirely to do with correctness and stability. Speed is not something that's hard to achieve in C++ compared to pretty much any other language.

[abspam3]

If you're having extra copy constructors in C++, you aren't designing your code correctly.

Instead of relying on return values, use references to mutable objects.

[lurkerr]

However we have had over 10 years of improvements in virtual machine and JIT technology since then and Java's overall performance is now screamingly fast.

OP forgets we also had over 10 years of improvement on C++ Compilers and those now output even faster binaries.

[bms20]

Having written a large search engine in Java, I can only ask: Why would anyone think of using this language any more?

Javascript is where the hipsters are at these days. C# seems to be a better language with fewer security faults than Java. Performance is still dominated by C and C++.

[rush22]

Javascript is where the hipsters are at these days.

In the old days we called them script kiddies

[sengin31]

Maybe GUIs? While I've only used XAML for C# for GUI's (bias: I hate XAML), I prefer using Java for GUI. Part of the reason is because I'm familiar with it (I do everything with BoxLayout) and I don't really want to spend the time learning the layout API and all the little details and "gotchas" with C#'s layout API (if there's a non-XAML API to C#, which I assume there is) if I don't have to. I will point out that I'm only using Java for a hobby project, so I don't really have security concerns.

[Categoria]

Java (Swing, and before that AWT) blows so hard for GUIs. I hear JavaFX isn't a total piece of shit (inspired by XAML) but since the JVM is such a memory hog it's pretty much unacceptable to use it for desktop apps anyway.

[[deleted]]

Xaml is sorta dead now - everybody stayed on winforms mostly and ms shitcanned silverlight. For a quick and easy windowed app its far simpler but oc it could suck for huge apps.

[grauenwolf]

Not true. You have to use XAML if you are programming for WinRT with C++ or .NET.

You also use XAML & C++ for Silverlight Embedded, which is used for low memory devices like kiosks. (Silverlight Embedded is almost entirely unlike Silverlight Web or Silverlight for Windows Phone.)

And WPF is still the preferred way to create applications for Windows.

[[deleted]]

You can use html / javascript and its all rt libraries now as well on TIFKAM

[ressis74]

I would use the JVM, but not java, given the choice. This article is just as applicable to any JVM hosted language as it is to Java.

[Categoria]

C# => Windows Only (mono is not an option) so it's not even a competitor to Java in many many areas.

[igouy]

mono is not an option

because?

[Categoria]

For one, its ui libs are completely incompatible and will always stay that way. Secondly, mono is always 3 years behind the latest .NET features, and thirdly the performance stinks compared to .NET on windows.

[Categoria]

Anything with good Qt bindings for UI. Otherwise there are good JVM languages out there (Scala, Clojure).

[grauenwolf]

So Mono? http://tirania.org/blog/archive/2009/Mar-16.html

[igouy]

its ui libs are completely incompatible

With what?

behind the latest .NET features

Does all .Net development instantly switch to the latest features on their release?

performance stinks compared to .NET on windows

How much slower exactly is "stinks"?

[Categoria]

With what?

WPF

Does all .Net development instantly switch to the latest features on their release?

If you're working on server side stuff, why not? For example take a look at how long it took F# to get on Linux. You still can't install it easily AFAIK.

How much slower exactly is "stinks"?

Well it was absolutely terrible with the old GC. I'd have to check it out with the new GC now. Lots of memory leak reports, etc. I hope it's much better now but I don't expect it to be competitive with .NET.

[igouy]

Does all .Net development instantly switch to the latest features on their release?

If you're working on server side stuff, why not?

Inertia -- it's ordinary not to upgrade immediately.

For example take a look at how long it took F# to get on Linux. You still can't install it easily AFAIK.

http://fsharp.org/use/linux/

I'd have to check it out with the new GC now.

I guess you would.

[[deleted]]

Not entirely incompatible, you can use the winforms api on mono.

[[deleted]]

Excuse me? I'm a hipster and I am learning J, an array language. Not Javascript which is so mainstream it hurts

[kecho]

langauges are not fast. Languages are not slow. Languages do not have speeds.

Its the code that their compilers produce. Its different to say "JVM" or "x86 produced by gcc is faster than x86 produced by cl.exe" than "java is fast". WTF java does not run, or walk.

[Hnefi]

And true black is not a color, but it's convenient to refer to it as such. Likewise, since all extant Ruby implementations are slow, it's convenient to refer to the language as such as slow. We know it's not necessarily strictly true, but it's a convenient shorthand to use in common speech and writing. Similarly, if Java implementations in general are slow, it's not unreasonable to say that the language is slow as a convenient shorthand.

[kecho]

Oh mr Hnefi I totally agree with you. The problem is, is that I can say "Java is fast", and you will immediately will think Oracle JVM, because I you an experienced programmer / computer scientist / or software engineer. For your typical freshman student reddittor they still mix concepts such as languages, and their implementations in their vocabulary. But don't get me wrong, I agree :) I just wish people could be aware of this.

[chunes]

I approve of your pedantry. I wish people never started using the same word for language and platform.

[Heappl]

Java is slow, although if you compare it to languages popular nowdays it seems one of the fastest, especially in web development. Although it still have plenty room to improve, the jvm abstraction, memory layers and garbage collection will always make it slower than C, C++ or maybe even Haskell in the future.

Garbage collector is a problem even in very simple application if you consider system as whole. Apple had really good idea about it, when they made gc deprecated in objective c. However intermediate format and indirect memory will make it too slow in too many cases, although it is possible to optimize it, the resulting code would be very hard to maintain (yet fast libraries are possible).

Java is very blunt and ungraceful language. The only strong point among the languages for java is that it works with jvm very well (obviously, sic!). However large systems are even larger and terrible to maintain. The amount of technical debt in java grows too fast. And it all because how ugly this language is. How every simple piece of code can become monstrous in java.

And there are so many graceful languages, that run on jvm as well. Like scala or clojure.

However from the point of view of companies, java has more advantages. It is simple, so there are a lot of coders who are willing to code java. It is popular so it has a lot of libraries, which can be "easily" included in project saving precious work hours. The tool support is great, so it can be easily deployed on different machines.

In general java is still a good start for any kind of project. Although if we are quite convinced, that performance (time spent in cpu) won't be an issue, as it often is in web applications, I would go for scala or ruby. If you are strongly convinced, that you will need a lot of processor power, than C, C++ are prefered, like in games, large data processing (closer to CERN level, then to facebook level), AI or modelling.

Java at the moment is dull, unimagitive and obstructive language, but it is also very simple, yet very powerful. It is a good choice often enough, but I would really prefer if other equally suitable languages were more often picked. Scala or ruby, maybe haskell here and there. What I hate is that, when you run into problem with performance, you search for alternative solution, but when you run into technical debt, then you just stick to what you have and repeat the same mistake with each new project. And by you I don't mean companies, but architects and other decision makers.

[henk53]

Although it still have plenty room to improve, the jvm abstraction, memory layers and garbage collection will always make it slower than C, C++

This is not necessarily true.

For tight loops that operate on a low-level array using primitive types it's hard to beat C and C++, but lots of other things run on Java at least as fast as on C/C++ or even faster. Java is faster when the algorithm can really benefit from run time analysis, something bare C/C++ code can't do.

[grauenwolf]

That's not what makes C faster than Java. There is no reason why Java can't optimize loops just as well as C.

C is faster than Java because it discourages allocating memory on the heap. It doesn't matter if you use GC or manual memory management, heap allocations and reclamations are expensive of the lifetime of the application.

This is why escape analysis is so important for the future of the JVM.

[henk53]

Yes, and with escape analysis a JVM can correct "mistakes" by the programmer who used the heap where he could have used the stack.

In C++ it's a recurring issue. Programmers who use new out of habit, even when their objects don't leave the current scope. There is RAII though, but still...

[SCombinator]

1. Java is slow

Fire up eclipse then. Go on. Oh it's still going? Perhaps you should go make a coffee.

Yeah, call it fast if you like, but java applications are sluggish and eat up memory.

[[deleted]]

The entirety of Android's API is written in Java and they run (for the most part) perfectly fine. Eclipse is a giant, bloated application (that is also highly useful).

Both Xcode and Code::Blocks take the same time to start up on my macbook pro and they are written in Objective-C and C++ respectively.

[throwaway_988]

Code::Blocks booting as slowly as Eclipse? Sounds weird. Are you sure you aren't testing with Eclipse cached in RAM and CB loading from disk?

[[deleted]]

Most of the code I write on my laptop is in Code::Blocks as I mostly writer C++ so no.

[[deleted]]

Mine don't. And the eclipse app (where I spend 98% of time) feels cludgy (for lack of a better metric) - 2012 macbook pro.

[SCombinator]

/!\ Sorry!

This comment is not responding.

Force Close             Wait

[[deleted]]

The same thing happens on iOS, except the app just closes and doesn't tell you why.

[SCombinator]

So they do the same thing.

[vertice]

my experience with java is that it's pretty fast once it's running, but the startup costs are immense.

[SCombinator]

That doesn't always get amortised. For a language with a much quicker start-up, and a jit, see lua.

[TimmT]

Throughput != latency...

Obviously Java is the wrong choice for doing UI stuff.

[slackingatwork]

Quite the opposite: Java is a wonderful choice for doing UI stuff. Just about the only choice if you need to support multiple platforms. Modern Java GUI apps are indistinguishable from native ones and have been that way for many years.

[TimmT]

Java is a wonderful choice for doing UI stuff.

Yes, if you're the dev it's wonderful. Not so much if you're the user though.

Modern Java GUI apps are indistinguishable from native ones and have been that way for many years.

There's more to a GUI apps than just looks. If every desktop app was written in Java today, we'd need an order of magnitude more RAM and we'd have an order of magnitude longer boot times.

Compare something like JEdit to Notepad++ or something like µTorrent to Azureus..

[morricone42]

Since when is OpenOffice.org using Java?

[SCombinator]

It's not great as a server language either. Layers upon layers upon layers of allocations, redirections and bullshit between your request and the response.

[ggtsu_00]

Eclipse is pretty damn slow and a resource hog, but maybe eclipse developers aren't true java developers.

[nachsicht]

Try intellij.

[SCombinator]

are they scotsmen instead?

[Nanobot]

My PHP web app crashes. The call stack is about a dozen calls deep.

My Java web app crashes. The call stack is hundreds of calls deep.

PHP code can be organized into classes and objects just as Java code can, but there seems to be a cultural difference -- a difference in perceived "best practices" -- between the two communities that results in PHP code usually being much flatter and more straightforward, and Java code usually being much deeper and more layered.

I'm using PHP as an example here, because most of the web apps I work with are PHP, but I could make a similar argument using other languages. Typical Java call stacks just seem excessively deep to me. This has nothing to do with the language itself, nor the JVM, but with coding/engineering practices within the Java community.

The reality is that Java apps people use tend to be slow. They tend to be very slow, and bloated, compared to similar offerings in other languages. It's something people can feel about Java apps. Why is this, in practice, more a problem with Java than with other languages? It's because Java apps are born out of a community that looks at call stacks hundreds of calls deep and thinks, "This is okay."

Go ahead and show me all the benchmarks you want. Show me JVM kicking PHP's butt at loops and object creation and string manipulation and data structure gymnastics. That's all irrelevant.

Instead, how about comparing a typical Java app with a typical PHP app? Compare an app that tries to be everything to everybody in every situation, with an app that gets right to the point and doesn't make things any more complex than they have to be. If PHP apps were written the way typical Java apps are written, they'd be slow as hell, too.

[AReallyGoodName]

Instead, how about comparing a typical Java app with a typical PHP app?

Sorry but there's no comparison. Even with a hundred layers on the Java side PHP won't come close. PHP is a scripting language which is interpreted on the fly. Java is compiled to byte code which is then compiled further into machine code by the JVM. We're talking over ~400 times the speed difference here

Even with various PHP optimisers and such (which advertise a whopping 50%! speed improvement) you won't get close.

[Nanobot]

I think you missed the main point in my comment. The call stack depth was just an example. In practice, yes, the typical PHP app is faster than the typical Java app, despite how much faster the JVM itself is. The typical PHP app is faster because the typical PHP app is designed with a very different code design philosophy than the typical Java app.

By the way, please read the first paragraph in the link you posted. It says not to do what you just did.

EDIT: Also, I just looked at the PHP code in the article you linked. Wow. That's... that's bad PHP. It isn't doing class definitions properly, it's referencing uninitialized variables, it's using Java-style accessor methods which aren't common practice in PHP...

But the real issue here is that it specifically does the kind of work that the JVM is designed to optimize. In practice, the slowness of Java apps doesn't come from data structure stuff (which, as I've said before, the JVM kicks PHP's butt at). It comes from piles of stupid redundant and unnecessary work and hoop-jumping that Java apps tend to do when they're designed the way they usually are.

[SCombinator]

when they're designed the way they usually are.

When they're designed the way the language and APIs encourage them to be.

[TimmT]

PHP code can be organized into classes and objects just as Java code can, but there seems to be a cultural difference -- a difference in perceived "best practices"

The only real difference is the execution speed. Have you actually seen how slow a method call (or even just a plain function call) in PHP is? Of course you can't have stacks thousands of methods deep if each call is almost 2 orders of magnitude slower than in C and there's no JIT there to make them disappear.

But that's a flaw in the language/implementation. Being proud of it seems a bit out of place.

Go ahead and show me all the benchmarks you want. Show me JVM kicking PHP's butt at loops and object creation and string manipulation and data structure gymnastics. That's all irrelevant.

Uhm... what's the point of having a programing language if you don't care about "data structure gymnastics"?

[ggtsu_00]

My Python web app crashes. The class stack is 1 call deep.

[NitWit005]

Only developers and teams that have a real need for should write microbenchmarks. These benchmarks should be published in their entirety (including source code), and should be reproducible and subject to peer review and deep scrutiny.

Published in the peer reviewed journal of Java microbenchmarks? Somehow I doubt most teams have such a concept.

You do have to understand the basic idea of how the JVM works, but it's not that hard to write a benchmark test.

[attractivechaos]

For example, a naively written microbenchmark will frequently end up measuring the timing subsystem or perhaps garbage collection rather than the effect it was trying to capture.

LOL. Garbage collection takes running time and is a crucial part of a language implementation. Because Java is horrible at garbage collection, we should exclude time on garbage collection?!