Slashdot Mirror
Swiss Firm Claims Boost In Android App Performance
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."
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.
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.
Mod me down, my New Earth Global Warmingist friends!
Check his wiki, this guy is the real deal. He is the architect of the BeOS file system, something that still hasn't been surpassed in flexibility and efficiency - the crown jewel of the BeOS code. Trolltech's QT also improved a lot under his reign. I would say that this guy knows a lot about writing optimized code, and Google should be very happy that he's turned his attention to Android. If I were Google, I'd be thinking hard about buying out this plucky little startup from Switzerland.
they are a founding member of the OHA, and claim to have 10% market share ("one out of ten phones in the market today") with their Jbed Java Mobile platform.
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.
"National Security is the chief cause of national insecurity." - Celine's First Law
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.
Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
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
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?
...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...
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..
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.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.