4 ms·

I stopped reading as soon as he trotted out the "JVM is slow" line. If you still believe this, you are ignoring reality or arguing from something some guy told

I stopped reading as soon as he trotted out the "JVM is slow" line. If you still believe this, you are ignoring reality or arguing from something some guy told you ten years ago. Yes, you can argue that in some cases, you can get about a 2x speedup with native code, or more by using hardware features not exposed in java (stream processing), but that's not relevant to the argument this guy appears to be making.

jrockway 16y ago
Yeah, but I tried opening Eclipse and it took a while for my 3400 RPM disk to read it into memory. Since Eclipse is written in Java, Java is slow! Incidentally, Visual Studio and KDevelop are native code, and they take a while to load too. Could it be that big bloated apps are big and bloated, VM or not?
- blub 16y ago
  Not only Eclipse is slow, but pretty much every Java program that I've tried. Also, a lot of code in Visual Studio is managed, especially in the UI.
loewenskind 16y ago
Actually the JVM is slow on startup. It has to decide if it's going to use the full Hotspot optimizer or something for shorter runs (Hotspot wont buy you anything for a short-running app like e.g. cat'ing a file). Given that many phone apps are going to be started, looked at and shut down within a few seconds I don't think the comment is completely out of line.
- ithkuil 16y ago
  dalvik is different. for example dalvik bytecode can be adapted to match host endianness after being installed Running JVM bytecode which is designed to be big-endian (sparc was big-endian) requires some adaptation when executed (especially when constants are loaded from the constants pool) on little endian machines (x84), it seems that the JIT compiler takes care of it. However I don't know how much does this inpact on the JIT compilation speed. furthermore dalvik wasn't even a jit until android 2.2. I assume that this startup latency issue was taken into heavy consideration when designing the dalvik JIT, can anyone point to any resources about this?

jrockway 16y ago

Yeah, but I tried opening Eclipse and it took a while for my 3400 RPM disk to read it into memory. Since Eclipse is written in Java, Java is slow! Incidentally, Visual Studio and KDevelop are native code, and they take a while to load too. Could it be that big bloated apps are big and bloated, VM or not?

blub 16y ago
Not only Eclipse is slow, but pretty much every Java program that I've tried. Also, a lot of code in Visual Studio is managed, especially in the UI.

loewenskind 16y ago

Actually the JVM is slow on startup. It has to decide if it's going to use the full Hotspot optimizer or something for shorter runs (Hotspot wont buy you anything for a short-running app like e.g. cat'ing a file). Given that many phone apps are going to be started, looked at and shut down within a few seconds I don't think the comment is completely out of line.

ithkuil 16y ago
dalvik is different. for example dalvik bytecode can be adapted to match host endianness after being installed Running JVM bytecode which is designed to be big-endian (sparc was big-endian) requires some adaptation when executed (especially when constants are loaded from the constants pool) on little endian machines (x84), it seems that the JIT compiler takes care of it. However I don't know how much does this inpact on the JIT compilation speed. furthermore dalvik wasn't even a jit until android 2.2. I assume that this startup latency issue was taken into heavy consideration when designing the dalvik JIT, can anyone point to any resources about this?