Swiss Firm Claims Boost In Android App Performance 132
Precision writes to inform us about the Swiss firm Myriad, which claims a 3x boost in Android app performance and longer battery life with a new virtual machine. Myriad says that its technology is 100% compatible with existing Android apps. "The tool is a replacement for the Dalvik virtual machine, which ships as part of the Android platform, and retains full compatibility with existing software. Dalvik Turbo also supports a range of processors including those based on ARM, Intel Atom, and MIPS Architectures."
Re:Another JVM (Score:3, Informative)
Keep a list of dead objects, and refill the variables to resurrect whatever's needed. The initial cost of heap allocation can be amortized to nothing that way, for long running program components. As a result, the GC won't be needed, and your performance will be independent of the GC algorithm.
Re:Proof? (Score:2, Informative)
No, anyone following the Dalvik VM and android knows it was barely optimized out of the gate.
Google's team has said they are going to optimize the vm as development progresses.
Benoit Schillings is the Chuck Norris of code. (Score:5, Informative)
Well... (Score:4, Informative)
So, it's not like it's some startup with no experience in that market, trying to make a name for itself. In fact, they would seem to have more to lose than gain by making overzealous claims.
Re:Benoit Schillings is the Chuck Norris of code. (Score:5, Informative)
You're thinking of Dominic Giampolo. Benoit wrote the App Kit and tons of good bits in the rest of BeOS but he didn't have much to do with the filesystem.
Re:Any technologically savvy want to enlighten me? (Score:4, Informative)
Google did not miss anything. They were well aware that Dalvik was largly unoptimized. They have been working on creating a JIT compiler for Dalvik, while this other company has been working on other improvements.
How to build a flawed API in Java... (Score:5, Informative)
How to build a flawed API in Java...
If a library's performance depends strongly on GC performance, then the programmers should refactor their code to reuse existing objects rather than building new ones all the time.
The absolute worst thing you can do in an object oriented language, which is intended to be used in an object oriented way, is to instance objects without the instancing of them initializing them. The original Java Mail API did this, and it was a steaming pile because of that. I would probably go so far as to suggest that any object oriented language which permitted this was not designed correctly. To reuse the objects, you'd have to be able to reinitialize them, which is basically the same thing.
The typical problem with Java programs and garbage collectors is chasing force-zeroing of pages because they release the memory back to the system, and their security model requires that the memory be zeroed before it is reused by the program. Being a little bit time lazy about doing your GC to reclaim the memory on behalf of the system rather than on behalf of the program you are running almost always results in significant performance improvements in things like Physics engines. In other words, you want a little intentional latency between the time you collect the garbage, and the time you deliver it to the dump.
One of the most obvious recent offenders is Apache Lucene , specifically , which works just great, if you don't do the finalize() and cause the objects to be collected way too early.
So the problem usually boils down to a greedy garbage collector, which is a problem in the JVM, not the library code.
Of course on tiny platforms, the JVM footprint gets pretty large, so you'd also need to gather and LRU the freed heap to avoid it growing out of control from the latency; so you'd need a high water mark as well as a timed delay.
Personally, I really hate garbage collection as a paradigm, especially the garbage collection in Objective C. It claims to be optional, but isn't: as soon as you have one framework that doesn't do an explicit release of an object, your program is forever after addicted to the garbage collector, and slowly accumulates leaks which are "fixed" by the garbage collector, until what you have left is code you can't reuse without also doing garbage collection, infecting any project you bring it into.
-- Terry
Re:Java vs Objective C - is iPhone always faster? (Score:3, Informative)
You seem to be conflating VMs and runtime environments with JIT compilation. So according to your logic if I JIT compile C code it will somehow run slower than AOT compiled C code? How does that make any sense?
Re:Java vs Objective C - is iPhone always faster? (Score:4, Informative)
...you can always write the performance sensitive guts of your iPhone app in C or C++ if the Objective-C run time proves to be the bottleneck in your particular case. After all it is GCC that compiles the Obj-C/C/C++ code on that platform...
Re:plucky little startup from Switzerland (Score:1, Informative)
Plucky little start-up indeed.. They were called Esmertec in a previous life, and have been around a long time (in mobile phone years). I believe they provide(d) the java implementation for a large share of Sony Ericsson handsets They merged with another company, purple labs, which also came out of a whole host of mobile phone software companies, including the Openwave client software division..
Re:Another JVM (Score:4, Informative)
There's nothing wrong with using Java on a resource constrained device. It works fine for most applications, although maybe not for realistic physics simulations.
Even relatively inattentive Java coding (with respect to constructing objects inadvertently) works fine for most things you'd want to do on a most devices you're likely to encounter. It's the usual thing, if you look at your code, only a tiny fraction of it tends to be performance critical.
Now I can't tell you how many hours I've spent dealing with messes created by crappy resource pooling implementations. The irony is that these were all classic examples of premature optimization. Competent programmers make things clear and correct first, then worry about fast. These incompetent implementations were from programmers who worried too much about the performance constraints of the platform and bent over backward trying to shoehorn in every optimization they could think of before ever getting a single jot of performance data. So they ended up with a buggy mess. After ripping all those optimizations out, including the resource pooling, I found that things ran *faster*, although that was less important than the fact the software was *correct*.
Now I agree that if I *were* writing something that had to be very fast (and something like a scientific simulation or cryptanalysis utility that can never be fast enough), and heap based object allocation and garbage collection were going to be a bottleneck, I'd choose something like C++ instead. It's purely a matter of optimizing programmer time either way. I don't want to have to waste my time worrying about optimization.
Re:How to build a flawed API in Java... (Score:3, Informative)
The absolute worst thing you can do in an object oriented language,
Perhaps you misunderstand the subject. Caching, memoizing, and/or object pools are all extremely common optimizations. On Android, its the ONLY way you're going to see a video game sustain reasonable FPS. End of discussion.
Its easy to re-initialize an object's state to allow for re-use after it has been instantiated. When the object's life is done, rather than free it, you simply return it to a pool. When a new object of that type is required, you re-initiate an existing instance, remove it from the pool, and return it. This way the object never needs to go through the garbage collector.
Even in languages without a garbage collector (C++), these optimizations are still fairly common and their use almost always increases performance. Additionally, their use in of themselves are never a bad idea unless the system you're on is extremely constrained by memory which prevents the creation of pools and/or caches.