Earlier quoted context omitted.
https://benchmarksgame.alioth.debian.org/u64q/java.html Consistently twice as slow, with memory usage between 2 and 400(!) times larger. Java is slow and bloated compared to native. Your next argument will be something about how micro-benchmarks don't reflect reality for larger programs...
It's interesting that the "gz" column, which reflects the amount of source code required, shows a very slight trend towards C being smaller, although there are big exceptions like regex-dna and reverse-complement. I'm not seeing the 400x more memory - there is a 40x though. But if you add up the columns for the programs that have both C and Java versions, you get this rough summary... secs KB gz Java 76.33 2004048 12…
JVM JIT optimization techniques
61–62 of 62 posts
Re: JVM JIT optimization techniques
#62Earlier quoted context omitted.
https://benchmarksgame.alioth.debian.org/u64q/java.html Consistently twice as slow, with memory usage between 2 and 400(!) times larger. Java is slow and bloated compared to native. Your next argument will be something about how micro-benchmarks don't reflect reality for larger programs...
I mean, micro-benchmarks are just generally not something to put a huge amount of stock into in general, regardless of language. Software that scales out to hundreds of thousands if not millions of users is generally written in "slow", "bloated" languages, and seems to be doing ok. It really all depends on the use case, and who is creating the software. Most enterprise software is slow and bloated, but a lot of other…
Not much for those programs:
http://benchmarksgame.alioth.debian.org/sometimes-people-jus...
>> It's pretty easy to see … memory