Live data from Hacker News

JVM JIT optimization techniques

advancedweb.hu

61–62 of 62 posts

Re: JVM JIT optimization techniques

#61

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…

>> more memory

http://programmers.stackexchange.com/a/189552/4334

Re: JVM JIT optimization techniques

#62

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...

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…

>> overhead of starting up the JVM both in time

Not much for those programs:

http://benchmarksgame.alioth.debian.org/sometimes-people-jus...

>> It's pretty easy to see … memory

Yes: http://programmers.stackexchange.com/a/189552/4334

Post reply on HN