Linked by Thom Holwerda on Thu 19th Jun 2014 09:58 UTC
Google

Ever since we first saw ART appear alongside the release of Android 4.4 KitKat, we all knew that it would eventually replace the aging and relatively inefficient Dalvik runtime compiler. Well folks, the time is now upon us, as commits made late last night to the AOSP master branch show Dalvik getting the axe and ART being set as the default.

Should deliver some decent performance improvements. I tried switching to ART months ago but ran into problems with some applications not working properly. Has the situation improved? Are any of you using ART?

Thread beginning with comment 590945
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Re:
by Bill Shooter of Bul on Thu 19th Jun 2014 16:42 UTC in reply to "Re:"
Bill Shooter of Bul
Member since:
2006-07-14

Uhm, ios is also switching to Swift. Because objective C has some real run time penalties that slow it down more than it needs to be slowed down. Late binding, swizzling, automatic garbage collection and exceptions all slow it down.

Reply Parent Score: 2

RE[2]: Re:
by CaptainN- on Thu 19th Jun 2014 17:26 in reply to "RE: Re:"
CaptainN- Member since:
2005-07-07

Swift compiles to machine code on iOS. Most languages compile to machine code on iOS - Java, C#, even Actionscript 3.0!

Reply Parent Score: 2

RE[2]: Re:
by Berend de Boer on Thu 19th Jun 2014 19:24 in reply to "RE: Re:"
Berend de Boer Member since:
2005-10-19

Automatic garbage collection does not slow things down. You need to collect garbage, which you can do:

1. Manually. Programmers can't be trusted to do that, very hard in case of cyclic references.

2. Reference counting: big overhead.

3. Automatic, best method, but requires a good gc, ideally something that has a multi-generation heap, can compact the heap, and can run concurrently without pauses.

Reply Parent Score: 1

RE[3]: Re:
by Bill Shooter of Bul on Thu 19th Jun 2014 21:20 in reply to "RE[2]: Re:"
Bill Shooter of Bul Member since:
2006-07-14

Well, it sounds like you are talking about garbage collection in the abstract.

In Objective C it was so bad, they never even made it available in ios, and are removing it from a future version.

http://en.wikipedia.org/wiki/Objective-C#Garbage_collection

Reply Parent Score: 3

RE[3]: Re:
by dpJudas on Thu 19th Jun 2014 21:44 in reply to "RE[2]: Re:"
dpJudas Member since:
2009-12-10

1. Manually. Programmers can't be trusted to do that, very hard in case of cyclic references.

And yet Modern C++ (shared_ptr+weak_ptr), Modern Objective C (ARC) and Swift (also ARC) are doing that just fine.

2. Reference counting: big overhead.

Depends. In most situations the overhead does not matter. On the other hand the overhead is constant, predictable and works for resource management as well.

3. Automatic, best method, but requires a good gc, ideally something that has a multi-generation heap, can compact the heap, and can run concurrently without pauses.

GC vs ARC have each their pros and cons. The big problem with the GC approach is that while memory is usually plentyful, other resources are not and the GC is incompatible with one of the easiest resource management tools: destructors. For example, for every place a C++ project uses scope and destructors, most GC based languages requires some kind of try/finally clause to ensure you do not get memory gathering or resource exhaustion issues.

And quite frankely most developers have just as hard a time remembering to type try/finally as they had remembering to type delete in the infamous 1990's C and C++ days.

Reply Parent Score: 2