Hacker News new | ask | show | jobs
by vmorgulis 3770 days ago
Swift is compiled. One can expect better performance.

The target is probably iOS developers.

3 comments

Swift gets most of its performance gains by not doing GC and better struct support.

I have a distaste for Java but it's performance problems stem mostly from the way people write it and how hard it discourages writing in a performant style.

Aren't these "performance gains" a wash due to the overhead of ARC?
Not really, reference counting is generally considered to be more performant than GC. GC can end up thrashing the cache and doesn't work very well when using more than 8 to 16 GB of RAM.

Even the linux kernel uses reference counting as you need a rc / gc system to solve some problems.

ARC just inserts the retain/release calls that you'd make anyway, pretty much everyone agrees that there are very few degenerate cases with ARC and in the vast majority of cases it does the best that can be done, which is why almost everyone uses ARC now. (You can still turn it off if you really want in ObjC)

I came across this explanation on StackExchange on the performance penalties with ARC:

>As for performance both have performance penalties. Automatic reference counting delivers a more consistent performance, no pauses, but slows down your application as a whole as every assignment of an object to a variable, every deallocation of an object, etc, will need an associated incrementation/decrementation of the reference counter, and taking care of reassigning the weak references and calling each destructor of each object being deallocated. GC does not have the performance penalty of ARC when dealing with object references however it incurs pauses while it is collecting garbage (rendering unusable for real-time processing systems) and requires a large memory space in order for it to function effectively such that it is not forced to run, thus pausing execution, too often.

>As you can see both have their own advantages and disadvantages, there is no clear cut ARC is better or GC is better, both are compromises.

>PS: ARC also becomes problematic when objects are shared across multiple threads requiring atomic incrementation/decrementation of the reference counter, which itself presents a whole new array of complexities and problems.

> Swift is compiled. One can expect better performance.Swift is compiled. One can expect better performance.

Since we are discussing targeting Android: Java (and Kotlin) are also compiled ahead of time by the Android Runtime (ART). This has been the case since Android 4.4 (KitKat) when ART became an optional replacement to Dalvik.

? Android apps are also compiled ahead of time right now (whether they are written in java or kotlin).
Don't you still have GC issues for heap allocation/destruction? Swift uses the ARC pattern so no GC lockups or performance issues.

[1] https://developer.apple.com/library/ios/documentation/Swift/...

I have spent a large amount of time optimizing Android apps and GC pauses are generally not the issue (as long as you don't do something stupid like allocating objects in draw calls).

I think that ARC is probably an overall better solution but as far as GC pauses are concerned, we have reached the point where they don't impact performances.