4 ms·

Yet Obj-C seems to get by quite fine, and everything is super-dynamic there. Being able to dynamically hack behavior is a huge boon when coding against a close

by dilap 11y ago

Yet Obj-C seems to get by quite fine, and everything is super-dynamic there. Being able to dynamically hack behavior is a huge boon when coding against a closed-source, 3rd party platform. Doesn't matter so much in an open-source context, where you can just modify code and ship your own version of the library if necessary.

pcwalton 11y ago
Depends what you mean by "just fine". Objective-C method dispatch is very slow. It's significantly slower than that of JavaScript, for example.
- Alphasite_ 11y ago
  They aren't are they? Cached method calls are fairly fast from what i've read. [1] https://www.mikeash.com/pyblog/performance-comparisons-of-common-operations-leopard-edition.html https://www.mikeash.com/pyblog/performance-comparisons-of-co...
  - pcwalton 11y ago
    According to that chart, Obj-C method calls are either 4.5x or 7.8x slower than C++ virtual method calls, depending on whether you're looking at 32- or 64-bit code. That alone is pretty bad. But it's even worse than that: I'm talking about devirtualized calls, which are far faster than virtual calls in C++. More importantly than just the call time, devirtualization can have outsized performance impact because it enables inlining, converting intraprocedural optimizations to interprocedural optimizations. The difference between inlining and not can easily be a 10x-level performance difference with an optimizing compiler like LLVM.
    - mpweiher 11y ago
      The chart is wrong for message sends. I've been measuring this for a long time, and get ~2.1ns for a message send vs. 1.2ns for a cached message send on a comparable machine. If you want inlining, use a static inline function.
- mariodiana 11y ago
  When does another language then become a case of premature optimization? I'm serious. If performance is an issue, you can profile Objective-C code and then either deal with the runtime directly, or rewrite critical portions in C. But I would think that there is a lot of Objective-C code out there that runs just fine without any fancy tricks like what I'm describing.
  - pcwalton 11y ago
    Sure, but that doesn't mesh with Swift's goals, as I understand them. The team seems to be positioning Swift as a language that will scale down to low-level performance-critical pieces in a way that Objective-C can't (though I may be wrong here since I'm not involved in that community very much).
    - mariodiana 11y ago
      No, I think you are right. My understanding is that Swift is supposed to scale down, as you say, and performance there is critical. I was considering things from the point of view of higher level programming. Thanks.
    - mpweiher 11y ago
      Well, they say they want that. But this is at best aspirational, it isn't true. Certainly not so far and as far as I can tell not in the foreseeable future. Quite frankly, I doubt it will ever be true, because in essence their claim is that they are building the Sufficiently Smart Compiler and despite all the problems now it will be totally awesome when they're done. Swift currently can't hold a candle to Objective-C on the performance front, which is why all the heavy lifting is done in Objective-C. As a small example, see how many articles there are on "Swift JSON parsing", then check what percentage of those call into the NSJSONSerialization Objective-C class to the actual, you know, parsing.
- dilap 11y ago
  Just fine in the sense that it's the dominant language on iOS, and iOS sets the bar, IMO, for snappy experiences on modern platforms. Stuff implemented in java and javascript, not so much. Maybe saying objc is cheating a little bit, because it's so easy to drop into straight C to optimize. But stuff like UITableView (edit: scroll => table) is all heavily based on objc message sending, and it's easy to get great scrolling perf using that api. I don't know the exact number, but you can get a lot of message sends done in 16ms. (Another example -- GitUp, insanely fast git client, objc.) (On the other hand, I do remember that C++ based BeOS on 66 MHz PowerPCs back in the day was double-insanely fast, so maybe Obj-C is slow, on a language level, and we just don't know it because everything else is so much slower, on an implementation level. But then again that stuff was all virtual calls. I just don't buy the argument that at the _system framework_ level dynamic dispatch is a barrier to good performance.)
  - pcwalton 11y ago
    > Just fine in the sense that it's the dominant language on iOS, and iOS sets the bar, IMO, for snappy experiences on modern platforms. > Stuff implemented in java and javascript, not so much. I agree with the data but not the conclusion. iOS' performance is great in spite of using Objective-C as its language, not because of it. The only performance-related features that Objective-C brings to the table are (a) being able to piggyback on the optimizations implemented in popular open source C++ compilers; (b) being compatible with C, so you can easily inline C into Objective-C when Objective-C's slow performance bites you; (c) not requiring tracing garbage collection. When you're actually in heavy Objective-C land with method calls in tight loops, performance is pretty bad, both because message sending is slow and because methods can't be devirtualized. Apple knows this, and they've basically reached the limit of what they can do without incompatible changes to the Objective-C semantics. Hence the performance-related design decisions in Swift. (As for UIScrollView/UITableView, I agree that they're very fast relative to Android or current Web browsers for example. I know the reasons for this and they have nothing to do with the implementation language. Algorithmic and engineering concerns often trump programming language performance.)
    - dilap 11y ago
- mpweiher 11y ago
  Actually, Objective-C message sending is extremely fast, only slightly slower than a C++ virtual method call and in the same ballpark as a function call (the relative cost has drifted from 40% to 2x higher depending on OS version and machine architecture) without much of an impact on applications. In addition, message-sending is extremely cheap compared to other operations, for example roughly 50x faster than object allocation. Last not least, in the few cases where messaging does become an issue, it is trivial to replace with more optimized dispatch, ranging from an IMP-cached send to a static inline function depending on the performance requirements and API boundaries in question.

by dilap 11y ago

pcwalton 11y ago

Depends what you mean by "just fine". Objective-C method dispatch is very slow. It's significantly slower than that of JavaScript, for example.

Alphasite_ 11y ago
They aren't are they? Cached method calls are fairly fast from what i've read. [1] https://www.mikeash.com/pyblog/performance-comparisons-of-common-operations-leopard-edition.html https://www.mikeash.com/pyblog/performance-comparisons-of-co...
- pcwalton 11y ago
  According to that chart, Obj-C method calls are either 4.5x or 7.8x slower than C++ virtual method calls, depending on whether you're looking at 32- or 64-bit code. That alone is pretty bad. But it's even worse than that: I'm talking about devirtualized calls, which are far faster than virtual calls in C++. More importantly than just the call time, devirtualization can have outsized performance impact because it enables inlining, converting intraprocedural optimizations to interprocedural optimizations. The difference between inlining and not can easily be a 10x-level performance difference with an optimizing compiler like LLVM.
  - mpweiher 11y ago
    The chart is wrong for message sends. I've been measuring this for a long time, and get ~2.1ns for a message send vs. 1.2ns for a cached message send on a comparable machine. If you want inlining, use a static inline function.
mariodiana 11y ago
When does another language then become a case of premature optimization? I'm serious. If performance is an issue, you can profile Objective-C code and then either deal with the runtime directly, or rewrite critical portions in C. But I would think that there is a lot of Objective-C code out there that runs just fine without any fancy tricks like what I'm describing.
- pcwalton 11y ago
  Sure, but that doesn't mesh with Swift's goals, as I understand them. The team seems to be positioning Swift as a language that will scale down to low-level performance-critical pieces in a way that Objective-C can't (though I may be wrong here since I'm not involved in that community very much).
  - mariodiana 11y ago
    No, I think you are right. My understanding is that Swift is supposed to scale down, as you say, and performance there is critical. I was considering things from the point of view of higher level programming. Thanks.
  - mpweiher 11y ago
    Well, they say they want that. But this is at best aspirational, it isn't true. Certainly not so far and as far as I can tell not in the foreseeable future. Quite frankly, I doubt it will ever be true, because in essence their claim is that they are building the Sufficiently Smart Compiler and despite all the problems now it will be totally awesome when they're done. Swift currently can't hold a candle to Objective-C on the performance front, which is why all the heavy lifting is done in Objective-C. As a small example, see how many articles there are on "Swift JSON parsing", then check what percentage of those call into the NSJSONSerialization Objective-C class to the actual, you know, parsing.
dilap 11y ago
Just fine in the sense that it's the dominant language on iOS, and iOS sets the bar, IMO, for snappy experiences on modern platforms. Stuff implemented in java and javascript, not so much. Maybe saying objc is cheating a little bit, because it's so easy to drop into straight C to optimize. But stuff like UITableView (edit: scroll => table) is all heavily based on objc message sending, and it's easy to get great scrolling perf using that api. I don't know the exact number, but you can get a lot of message sends done in 16ms. (Another example -- GitUp, insanely fast git client, objc.) (On the other hand, I do remember that C++ based BeOS on 66 MHz PowerPCs back in the day was double-insanely fast, so maybe Obj-C is slow, on a language level, and we just don't know it because everything else is so much slower, on an implementation level. But then again that stuff was all virtual calls. I just don't buy the argument that at the _system framework_ level dynamic dispatch is a barrier to good performance.)
- pcwalton 11y ago
  > Just fine in the sense that it's the dominant language on iOS, and iOS sets the bar, IMO, for snappy experiences on modern platforms. > Stuff implemented in java and javascript, not so much. I agree with the data but not the conclusion. iOS' performance is great in spite of using Objective-C as its language, not because of it. The only performance-related features that Objective-C brings to the table are (a) being able to piggyback on the optimizations implemented in popular open source C++ compilers; (b) being compatible with C, so you can easily inline C into Objective-C when Objective-C's slow performance bites you; (c) not requiring tracing garbage collection. When you're actually in heavy Objective-C land with method calls in tight loops, performance is pretty bad, both because message sending is slow and because methods can't be devirtualized. Apple knows this, and they've basically reached the limit of what they can do without incompatible changes to the Objective-C semantics. Hence the performance-related design decisions in Swift. (As for UIScrollView/UITableView, I agree that they're very fast relative to Android or current Web browsers for example. I know the reasons for this and they have nothing to do with the implementation language. Algorithmic and engineering concerns often trump programming language performance.)
  - dilap 11y ago
mpweiher 11y ago
Actually, Objective-C message sending is extremely fast, only slightly slower than a C++ virtual method call and in the same ballpark as a function call (the relative cost has drifted from 40% to 2x higher depending on OS version and machine architecture) without much of an impact on applications. In addition, message-sending is extremely cheap compared to other operations, for example roughly 50x faster than object allocation. Last not least, in the few cases where messaging does become an issue, it is trivial to replace with more optimized dispatch, ranging from an IMP-cached send to a static inline function depending on the performance requirements and API boundaries in question.