5 ms·

Its interesting how languages divide opinion. For me I think Swift is the best language around. One of the issues not addressed in the article (I believe) is pe

Its interesting how languages divide opinion. For me I think Swift is the best language around. One of the issues not addressed in the article (I believe) is performance, Swift is faster than Objective C because of the static type checking, which is a good thing. It has the advantages of C# as a language but no garbage collection, granted the reference counting in Swift can be problematic, but it seems to be improving with each release. The functional programming aspect of swift I find useful. There are a number of features in swift that decreases the amount of code - e.g. if let/guard. The use of optional types increases program safety. The fact that you can use classes declared elsewhere without any consideration of dependency I find very powerful, and of course with great power comes great responsibility. The power of swift collections is fantastic, and the syntax compared to Objective C is so succinct. Many more...

sheeshkebab 8y ago
Faster than ObjC? Unless your objc code is written using nothing but id and reflection, I’m not sure how can this be the case...
- saagarjha 8y ago
  > Unless your objc code is written using nothing but id and reflection That's how all Objective-C code is written–every method call goes through objc_msgSend.
  - sitharus 8y ago
    To be fair to objc_msgSend it's orders of magnitude faster than most reflection APIs. https://www.mikeash.com/pyblog/performance-comparisons-of-common-operations.html https://www.mikeash.com/pyblog/performance-comparisons-of-co... has some benchmarks, it's a bit old but I don't think objc_msgSend would get slower.
    - saagarjha 8y ago
      Yup, I'm not saying objc_msgSend is slow: it's just that it's not faster than a direct call, and I believe about on-par with a virtual function call.
- Derbasti 8y ago
  And let's not forget that ObjC is downwards compatible with C. If you need a particular loop or function to be fast, you can write it in C, in the same ObjC source file.
- archagon 8y ago
  For one, ObjC can't treat objects as values or initialize them on the stack. Also, the everything-is-an-object paradigm is terrible for arrays of values, since every NSNumber or NSValue has to be individually malloced and released. (Though maybe not the case anymore? It was certainly a chokepoint several years ago.) Both of these factors have forced me into using lower-level Objective-C++ code on numerous occasions.
  - mercutio2 8y ago
    NSNumbers are generally tagged pointers, unless you’ve got a really large number.
    - deleted 8y ago
      [deleted]
    - archagon 8y ago
      This didn't help me in my app, unfortunately, because I needed to encode CGPoints as NSValues. I suppose I could have resorted to ordinary, interleaved CGFloats, but it was way easier and more productive to just use C++ vectors. I knew exactly what I was getting with those, and I didn't have to do the boxing/unboxing dance.
jakobegger 8y ago
I'm a big Swift fan as well, but the performance part simply isn't true. Swift was supposed to be potentially faster than Obj-C because of types, but in practice I have never seen that. Since it is missing mutable arrays and strings, your code often ends up copying a lot of memory around if you're not extremely careful, and you quickly get accidentally quadratic complexity. A lot of APIs are just wrappers around ObjC APIs, with lots of memory management calls required for bridging. You really need to be careful what calls you put in a tight loop. And that's before you even start with the good stuff. Protocols with associated types are so slow that they are unusable for anything performance sensitive. Theoretically the compiler should be able to optimize it incredibly well since it's all statically typed, but in practice the compiler seems to never be smart enough. Call stacks get very deep very quickly (protocol witnesses, closures, ...). In my experience the easiest way to make Swift code fast is to rewrite hotspots in ObjC.
- woolvalley 8y ago
  There is a lot of maturity left in the language for it to grow into. I typically say that it takes 10 years for a language to be mature enough to avoid stupid crap like you describe.
- trevor-e 8y ago
  Sorry but this is completely false, Swift is certainly faster than ObjC. There are several WWDC talks, independent reviews, and the language designers themselves supporting that. In practice I agree it's easy to write code that's slow, but you can't knock the language itself for user error. They are still working on improving the user experience, such as how 4.2 will remove redundant generated retain/release calls. And hopefully they make the compiler smarter at figuring out which specialization functions to output for generics/protocols.
  - Froyoh 8y ago
    This is false, that is false, I don't know who to believe.
    - 8y ago
mpweiher 8y ago
> performance, Swift is faster than Objective C No it's not. > because of the static type checking, which is a good thing That's a reason why you think it should be faster. Actual performance is measured, not argued. When you actually measure Swift, it is horribly slow. UPDATE: details in other posts here. In general, my measurements have found Swift code to be 50% to 50x slower.
- archagon 8y ago
  I've found it to only be slower in Debug, not Release builds. Release is often significantly faster than the equivalent ObjC, and only a tiny bit slower than native C.
  - mpweiher 8y ago
    Hmmm...you do realize that Objective-C is a full superset of C, so "Objective-C vs. native C" is not a distinction that makes sense? If you are comparing primitive types in Swift with objects in Objective-C, then you are comparing apples to oranges. You need to compare objects in Swift with objects in Objective-C and primitive types in Swift with primitive types in Objective-C. Rephrasing, my findings are similar: Swift in debug mode is so incredibly slow that even using primitive types with Swift is slower than Objective-C objects. In release mode, it approaches, but rarely reaches native Objective-C speed. More details here: http://blog.metaobject.com/2014/09/no-virginia-swift-is-not-10x-faster.html http://blog.metaobject.com/2014/09/no-virginia-swift-is-not-...
jrs95 8y ago
The performance improvements aren't exactly because of static typing. Obj-C method calls are slower because it uses dynamic dispatch (literal message passing vs a C style function invocation IIRC), whereas Swift generally only does this for interop with Obj-C.
fulafel 8y ago
> [...] no garbage collection, granted the reference counting in Swift can be problematic, but it seems to be improving with each release. nitpick: reference counting is a form of GC in standard CS terminology. It saves some memory compared to other GC methods but is slowish.
- chadcmulligan 8y ago
  reference counting is deterministic, GC isn't, which was always the apple engineers objection to GC - no pause while the collector runs.
  - beureum 8y ago
    There exist pauseless GCs, Apple's objection to GC is that GCs need more RAM, and that would reduce their profit margin on iPhones. A fair reason if you ask me.
    - deleted 8y ago
      [deleted]
  - fulafel 8y ago
    Reference counting has pauses, as object deallocations cascade. You can address this by having a deallocation work list that runs a bit at a time, but then again there is also a large body of work on other kinds of GCs that address pauses.

sheeshkebab 8y ago

Faster than ObjC? Unless your objc code is written using nothing but id and reflection, I’m not sure how can this be the case...

saagarjha 8y ago
> Unless your objc code is written using nothing but id and reflection That's how all Objective-C code is written–every method call goes through objc_msgSend.
- sitharus 8y ago
  To be fair to objc_msgSend it's orders of magnitude faster than most reflection APIs. https://www.mikeash.com/pyblog/performance-comparisons-of-common-operations.html https://www.mikeash.com/pyblog/performance-comparisons-of-co... has some benchmarks, it's a bit old but I don't think objc_msgSend would get slower.
  - saagarjha 8y ago
    Yup, I'm not saying objc_msgSend is slow: it's just that it's not faster than a direct call, and I believe about on-par with a virtual function call.
Derbasti 8y ago
And let's not forget that ObjC is downwards compatible with C. If you need a particular loop or function to be fast, you can write it in C, in the same ObjC source file.
archagon 8y ago
For one, ObjC can't treat objects as values or initialize them on the stack. Also, the everything-is-an-object paradigm is terrible for arrays of values, since every NSNumber or NSValue has to be individually malloced and released. (Though maybe not the case anymore? It was certainly a chokepoint several years ago.) Both of these factors have forced me into using lower-level Objective-C++ code on numerous occasions.
- mercutio2 8y ago
  NSNumbers are generally tagged pointers, unless you’ve got a really large number.
  - deleted 8y ago
    [deleted]
  - archagon 8y ago
    This didn't help me in my app, unfortunately, because I needed to encode CGPoints as NSValues. I suppose I could have resorted to ordinary, interleaved CGFloats, but it was way easier and more productive to just use C++ vectors. I knew exactly what I was getting with those, and I didn't have to do the boxing/unboxing dance.

jakobegger 8y ago

I'm a big Swift fan as well, but the performance part simply isn't true. Swift was supposed to be potentially faster than Obj-C because of types, but in practice I have never seen that. Since it is missing mutable arrays and strings, your code often ends up copying a lot of memory around if you're not extremely careful, and you quickly get accidentally quadratic complexity. A lot of APIs are just wrappers around ObjC APIs, with lots of memory management calls required for bridging. You really need to be careful what calls you put in a tight loop. And that's before you even start with the good stuff. Protocols with associated types are so slow that they are unusable for anything performance sensitive. Theoretically the compiler should be able to optimize it incredibly well since it's all statically typed, but in practice the compiler seems to never be smart enough. Call stacks get very deep very quickly (protocol witnesses, closures, ...). In my experience the easiest way to make Swift code fast is to rewrite hotspots in ObjC.

woolvalley 8y ago
There is a lot of maturity left in the language for it to grow into. I typically say that it takes 10 years for a language to be mature enough to avoid stupid crap like you describe.
trevor-e 8y ago
Sorry but this is completely false, Swift is certainly faster than ObjC. There are several WWDC talks, independent reviews, and the language designers themselves supporting that. In practice I agree it's easy to write code that's slow, but you can't knock the language itself for user error. They are still working on improving the user experience, such as how 4.2 will remove redundant generated retain/release calls. And hopefully they make the compiler smarter at figuring out which specialization functions to output for generics/protocols.
- Froyoh 8y ago
  This is false, that is false, I don't know who to believe.
  - 8y ago

mpweiher 8y ago

> performance, Swift is faster than Objective C No it's not. > because of the static type checking, which is a good thing That's a reason why you think it should be faster. Actual performance is measured, not argued. When you actually measure Swift, it is horribly slow. UPDATE: details in other posts here. In general, my measurements have found Swift code to be 50% to 50x slower.

archagon 8y ago
I've found it to only be slower in Debug, not Release builds. Release is often significantly faster than the equivalent ObjC, and only a tiny bit slower than native C.
- mpweiher 8y ago
  Hmmm...you do realize that Objective-C is a full superset of C, so "Objective-C vs. native C" is not a distinction that makes sense? If you are comparing primitive types in Swift with objects in Objective-C, then you are comparing apples to oranges. You need to compare objects in Swift with objects in Objective-C and primitive types in Swift with primitive types in Objective-C. Rephrasing, my findings are similar: Swift in debug mode is so incredibly slow that even using primitive types with Swift is slower than Objective-C objects. In release mode, it approaches, but rarely reaches native Objective-C speed. More details here: http://blog.metaobject.com/2014/09/no-virginia-swift-is-not-10x-faster.html http://blog.metaobject.com/2014/09/no-virginia-swift-is-not-...

jrs95 8y ago

The performance improvements aren't exactly because of static typing. Obj-C method calls are slower because it uses dynamic dispatch (literal message passing vs a C style function invocation IIRC), whereas Swift generally only does this for interop with Obj-C.

fulafel 8y ago

> [...] no garbage collection, granted the reference counting in Swift can be problematic, but it seems to be improving with each release. nitpick: reference counting is a form of GC in standard CS terminology. It saves some memory compared to other GC methods but is slowish.

chadcmulligan 8y ago
reference counting is deterministic, GC isn't, which was always the apple engineers objection to GC - no pause while the collector runs.
- beureum 8y ago
  There exist pauseless GCs, Apple's objection to GC is that GCs need more RAM, and that would reduce their profit margin on iPhones. A fair reason if you ask me.
  - deleted 8y ago
    [deleted]
- fulafel 8y ago
  Reference counting has pauses, as object deallocations cascade. You can address this by having a deallocation work list that runs a bit at a time, but then again there is also a large body of work on other kinds of GCs that address pauses.