3 ms·

An important aspect of mobile performance that this article doesn't really go into is memory. Its not just about CPU speed. Java performs quite close to C when

by sagargv 13y ago

An important aspect of mobile performance that this article doesn't really go into is memory. Its not just about CPU speed. Java performs quite close to C when excess memory is available, but performs poorly under low memory conditions. This is true of all GCed langs. The fact that iOS apps feel snappier is in no small part due to better memory management (ARC). Source: Why mobile web apps are slow - http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/ http://sealedabstract.com/rants/why-mobile-web-apps-are-slow...

pkolaczk 13y ago
This benchmark had nothing to do with low memory conditions. Also modern GCs do not add really that much memory overhead. Typical manual memory allocators bookkeeping/fragmentation have comparable overheads (~10-30%). Problems of Java being memory intensive lie elsewhere - e.g. lack of object inlining (too many pointers everywhere), wide-strings as default, lack of lightweight structures (two words overhead per object), the VM itself, huge OOP libraries (even if you need a single method you need to load a whole class into memory). 90% of memory taken up by my Java IDE is code. BTW: Your link is about JS, not Java. Performance problems of JS have little to do with GC, there are much bigger problems first.
- sagargv 13y ago
  Modern GCs do not add much overhead when excess memory is available. When the app itself consumes a lot of memory and there is little room available, the GC gets stressed and eats too much CPU time. The chart in the link (taken from some paper) depicts this. The problem is the GC under low memory conditions, not Java. Yes, the link is about JS. But there are relevant pieces. Quote from the article: "If you want to process camera images on Android phones for real-time object recognition or content based Augmented Reality you probably heard about the Camera Preview Callback memory Issue. Each time your Java application gets a preview image from the system a new chunk of memory is allocated. When this memory chunk gets freed again by the Garbage Collector the system freezes for 100ms-200ms. This is especially bad if the system is under heavy load (I do object recognition on a phone – hooray it eats as much CPU power as possible). If you browse through Android’s 1.6 source code you realize that this is only because the wrapper (that protects us from the native stuff) allocates a new byte array each time a new frame is available. Build-in native code can, of course, avoid this issue."

by sagargv 13y ago

pkolaczk 13y ago

This benchmark had nothing to do with low memory conditions. Also modern GCs do not add really that much memory overhead. Typical manual memory allocators bookkeeping/fragmentation have comparable overheads (~10-30%). Problems of Java being memory intensive lie elsewhere - e.g. lack of object inlining (too many pointers everywhere), wide-strings as default, lack of lightweight structures (two words overhead per object), the VM itself, huge OOP libraries (even if you need a single method you need to load a whole class into memory). 90% of memory taken up by my Java IDE is code. BTW: Your link is about JS, not Java. Performance problems of JS have little to do with GC, there are much bigger problems first.

sagargv 13y ago
Modern GCs do not add much overhead when excess memory is available. When the app itself consumes a lot of memory and there is little room available, the GC gets stressed and eats too much CPU time. The chart in the link (taken from some paper) depicts this. The problem is the GC under low memory conditions, not Java. Yes, the link is about JS. But there are relevant pieces. Quote from the article: "If you want to process camera images on Android phones for real-time object recognition or content based Augmented Reality you probably heard about the Camera Preview Callback memory Issue. Each time your Java application gets a preview image from the system a new chunk of memory is allocated. When this memory chunk gets freed again by the Garbage Collector the system freezes for 100ms-200ms. This is especially bad if the system is under heavy load (I do object recognition on a phone – hooray it eats as much CPU power as possible). If you browse through Android’s 1.6 source code you realize that this is only because the wrapper (that protects us from the native stuff) allocates a new byte array each time a new frame is available. Build-in native code can, of course, avoid this issue."