3 ms·

I almost skipped this link; I assumed it was typical borring blog noise. It's not. This is an insightful post from the git mailing list which shows some of the

I almost skipped this link; I assumed it was typical borring blog noise. It's not. This is an insightful post from the git mailing list which shows some of the real limitations that a top tier developer hits when trying to write Java code as fast as neatly optimized C code. Definitely worth reading.

nickik 15y ago
Same here. Nothing groundbreaing about Java vs C threw. Edit: I mean most of the problems (maybe features) of java are known.
kokey 15y ago
Actually, it also makes me want to get into another project in C again.
- jgw 15y ago
  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]
  - hello_moto 15y ago
    You won't know what you're missing until you don't have them :).
jaylevitt 15y ago
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.
- huherto 15y ago
  > "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.
  - yassim 15y ago
    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.
  - willy1234x1 15y ago
    He actually qualified it before that part of his comment. >Shawn is a performance-obsessed Java expert, Eclipse committer and longtime Google coder who works on JGit.
- Stormbringer 15y ago
  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.
pconf 15y ago
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.

nickik 15y ago

Same here. Nothing groundbreaing about Java vs C threw. Edit: I mean most of the problems (maybe features) of java are known.

kokey 15y ago

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

jgw 15y ago
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]
- hello_moto 15y ago
  You won't know what you're missing until you don't have them :).

jaylevitt 15y ago

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.

huherto 15y ago
> "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.
- yassim 15y ago
  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.
- willy1234x1 15y ago
  He actually qualified it before that part of his comment. >Shawn is a performance-obsessed Java expert, Eclipse committer and longtime Google coder who works on JGit.
Stormbringer 15y ago
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.

pconf 15y ago

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.