Yep. The usual "Program X is faster in C than Java" gets a barrage of "That's because you know C better". Shawn is a performance-obsessed Java expert, Eclipse committer and longtime Google coder who works on JGit. If he says Java is slower than C at this, then Java is slower than C at this.

EDIT: but as wcoenen points out, this was written in 2009 and Java 1.7 does a better job with some of this.

> "If he says Java is slower than C at this, then Java is slower than C at this."

Yes. I like how you qualify the statement. Furthermore, on the C side you have Linus and other C gurus that really, really know how to exploit the strengths of the C language.

I would also expect them to know how it works _all_ the way down through the OS, which can also have an impact on performance. IE, they know how the supporting systems operate thus can make further assumptions/optimisations.

He's an expert you say? That was certainly not my expectation from the article.

(1) Blind faith in Generics.

This alone screams newb to me. He says that he got better performance with a custom data structure (no shit sherlock) but then seems deeply surprised by this. Duh. Okay, well, obviously he's relatively new to Java, but hey, he could still be a performance expert.

(2) Never mentions the biggest weapon in the C vs Java arsenal. The thing is that C is only able to make optimisations up to a certain point, but there are optimisations that can only be made at run time not at compile time. So Java starts off behind, but can catch up some or even all of that distance.

People have used this to demonstrate Java code running faster than C code, but that is old news, a newb might not know this.

(3) Does not mention the second biggest weapon in Java's arsenal in the Java vs C speed argument. That being that more recent versions of garbage collection allow for super fast memory allocation - enormously much faster than what you get with malloc.

(4) Never quantifies how much slower Java is. If Java is 5 or 10% slower, then Meh, is that really news? If Java is 2x slower than carefully hand-tuned C by guys with actual code writing credentials like Linus, then that is still pretty good. 2x screamingly fast is still more than good enough for most people. If the difference is an order of magnitude, then that is not so good. If the difference is two orders of magnitude, then you might as well be using some scripting language.

A proper expert would certainly have quantified the speed difference.

I believe he is simply just counting his experience while porting GIT to Java. No where did I find that he claims he's an expert. What he did was providing his experience on the trenches.

In case if you are the expert, I would assume that he wouldn't mind if you have any insights to tune in the performance of JGit even further. You can start by joining in the mailing list.

He wasn't quantifying anything since he was not answering your question, he was sharing his experience.

Kids here should read the dragon book and then this argument will just be "ahh duhh."

In theory, any VM language will be slower than a memory managed app.

Then again, the dragon book is hard :)

Actually, it also makes me want to get into another project in C again.

So this.

It's truly liberating to get back to C after having programmed in something higher level for a long time. It actually makes me appreciate C more. I mean, at first, I shoot myself in the foot, elbow and groin with alarming regularity, but it's nice to actually have access to the bullets. :) [EDIT: dodgy grammar]

You won't know what you're missing until you don't have them :).

I wonder why none of these benchmarks measure the performance of _optimized_ Java? All of our builds use Proguard optimization and some of the resulting bytecode is noticeably faster.

Same here. Nothing groundbreaing about Java vs C threw.

Edit: I mean most of the problems (maybe features) of java are known.