3 ms·

Todd, you owe me $20. (Todd said this would never happen) Also, this is great news, and it will be interesting to see what kind of real-world changes in perfo

Todd, you owe me $20. (Todd said this would never happen) Also, this is great news, and it will be interesting to see what kind of real-world changes in performance this has.

mpweiher 4y ago
Things will get even slower.
- zuhsetaqi 4y ago
  Why do you think it’ll be slower? The article says the opposite
- KerrAvon 4y ago
  Available data so far seems to show that the pure Swift implementations are faster than the Objective-C ones even when called from ObjC clients. I don't have a link, so feel free to treat as hearsay, but FYI.
  - mpweiher 4y ago
    You don't have a link to the data because this is not true. Swift is generally slower than Objective-C, often significantly so. There are cases where it is faster, but those are rare. Yes, I have measured. One example is JSON and Swift codable, which is comically slow, see: Somewhat Less Lethargic JSON Support for iOS/macOS, Part 1: The Status Quo https://blog.metaobject.com/2020/04/somewhat-less-lethargic-json-support.html https://blog.metaobject.com/2020/04/somewhat-less-lethargic-... Punch line: Swift codable does around 10MB/s, despite all the supposed performance goodies and compiler support everyone always talks about and nobody appears to ever measure. A pure Objective-C implementation does 284MB/s. I also did a more general survey for my book[1]. While that's been a while, I haven't seen any indication that things have fundamentally changed, and lots of indications that they haven't.
    - astrange 4y ago
      This largely depends on how much of Swift<>ObjC bridging you'll hit, as such it'll get faster if more of Foundation is converted to Swift. In particular Swift is more memory efficient than ObjC because there's less boxing overhead to small values. That should matter more than the overhead from more overflow checking.
      - mpweiher 4y ago
        > Swift<>ObjC bridging This is another commonly held belief that doesn't hold up to actual measurements. For an example, see part 2: https://blog.metaobject.com/2020/04/somewhat-less-lethargic-json-support_12.html https://blog.metaobject.com/2020/04/somewhat-less-lethargic-... All the pure Swift implementations are even slower than the bridged ones, and the bridged ones are slower than the most comically inefficient Objective-C one (using KVC, for example), which is slower than the reasonable Objective-C ones. > In particular Swift is more memory efficient than ObjC ... It's not. > ... because there's less boxing overhead to small values You would think, yes. I actually did think that as well. Because it really sounds plausible. So imagine my surprise when I measured some common cases for my book (Chapter 9) and it turned that even in the cases where I just knew™ that Swift would be faster, because of this very reason, it just wasn't. > That should matter more than the overhead from more overflow checking. Computers don't care what you think "should" be the case, and they cannot be argued into better performance due to plausible arguments and strongly held beliefs. You need to measure what actually is the case.
- acdha 4y ago
  What are you basing that on? It seems unlikely that they'd reverse the ongoing trend of improved performance, especially at a time when they're shedding backwards compatibility concerns with the migration to ARM removing the least-maintained apps.
- klodolph 4y ago
  Just to explain why Objective C code, in practice, is not especially fast: You generally make the choice between writing something in pure C, which gives you plenty of performance but little safety, or using Objective C classes and methods, which gives you plenty of safety but you're paying the price for dynamic dispatch (objc_msgSend) and pointer indirections all the time. Swift makes it easier to eliminate things like dynamic dispatch while still keeping the safety. So it should be normal and expected that a rewrite from Objective C to Swift would result in a speedup (and increase in code size).
  - dilap 4y ago
    In practice would be what the resulting apps turn out like. In my experience, old-school ObjC iOS and Mac apps generally tended to be quite snappy. On the other hand, the new Swift hotness of Messages and Settings on macOS are noticably slower than what they're replacing. Of course I haven't done a comprehensive inventory, but I certainly don't have the general impression of things getting faster with Swift. (Are there examples of this?) My guess is any theoretical gains are generally swamped by the language culture of complex abstractions.
    - klodolph 4y ago
      Somebody rewrote an app in Swift -> the app is slower. Somebody rewrote a library in Swift -> the library is faster. There's a lot to talk about and unpack here. My experience is that people develop a different mindset when they do library development, because any code that they write will be code that they're forced to support for decades to come. You put bad code in an app and you can simply rip it out with the next revision, no questions asked. So you are much more likely to end up with questionable code in an app than in a library. I'm also old enough to remember not only the same complaints when people were rewriting apps into Objective C (lots of early Mac OS X apps were Carbon, including Finder), but when the same complaints were made about rewrites from assembler into C. Every decade your computer has a hundred times more computing power and your code takes 10x as much footprint, so you come out ahead, on average. It's just that any given year you might come out behind.
    - saagarjha 4y ago
- lostlogin 4y ago
  What has been getting slower for you?
hinkley 4y ago
I really should have started using Long Bets years ago. Ten years ago a “Tanya” told me she would never use an ebook to read literature. I’m pretty sure if I went to her house today I’d find 2. In fact I may be the only person I know who doesn’t own one (not wanting one and being fundamentally against them are two different things). That’s the most memorable but I’ve had these sorts of “over my dead body” conversations on a hundred topics over the years.
- astrange 4y ago
  I'm confused by the idea of searching someone's house for ebooks. Does that include PDFs?
  - latexr 4y ago
    > confused by the idea of searching someone's house for ebooks. GP probably meant “ereader”.
- eimrine 4y ago
  Maybe Tanya reads a lot of PDF as kind of default format for all kinds of technical things and very common format for downloadable ebooks. AFAIK ebook readers are terrible in pdf rendering.
  - deathanatos 4y ago
    > AFAIK ebook readers are terrible in pdf rendering. They're not really comparable formats. PDFs are documents rendered onto virtual paper: there is only so much a mobile device can do there, as a PDF is likely rendered as an 8½ by 11 or A4, which isn't going to be great on a tiny mobile screen. Bad tradeoffs between tiny text or pan-and-scan. eBooks, OTOH, are reflowable: ePub is "just" a ZIP of HTML¹. But the viewer can lay them out appropriately, so they can be formatted to fit your device, whether that's a tablet, a phone, or something else. IMO if you want to read something on a device, ePub > PDF for those reasons. PDF is good for print, & ensuring that what comes out of the printer has a shot at resembling the screen. (Though there are a good number of print settings to mess that up, too.) And, as a passably portable document format, if you're just doing short term viewing or something. ¹Plus a lot of other metadata that I'm eliding; it's a fair bit more complicated, of course.
deleted 4y ago
[deleted]

Todd, you owe me $20. (Todd said this would never happen) Also, this is great news, and it will be interesting to see what kind of real-world changes in performance this has.

mpweiher 4y ago

Things will get even slower.

zuhsetaqi 4y ago
Why do you think it’ll be slower? The article says the opposite
KerrAvon 4y ago
Available data so far seems to show that the pure Swift implementations are faster than the Objective-C ones even when called from ObjC clients. I don't have a link, so feel free to treat as hearsay, but FYI.
- mpweiher 4y ago
  You don't have a link to the data because this is not true. Swift is generally slower than Objective-C, often significantly so. There are cases where it is faster, but those are rare. Yes, I have measured. One example is JSON and Swift codable, which is comically slow, see: Somewhat Less Lethargic JSON Support for iOS/macOS, Part 1: The Status Quo https://blog.metaobject.com/2020/04/somewhat-less-lethargic-json-support.html https://blog.metaobject.com/2020/04/somewhat-less-lethargic-... Punch line: Swift codable does around 10MB/s, despite all the supposed performance goodies and compiler support everyone always talks about and nobody appears to ever measure. A pure Objective-C implementation does 284MB/s. I also did a more general survey for my book[1]. While that's been a while, I haven't seen any indication that things have fundamentally changed, and lots of indications that they haven't.
  - astrange 4y ago
    This largely depends on how much of Swift<>ObjC bridging you'll hit, as such it'll get faster if more of Foundation is converted to Swift. In particular Swift is more memory efficient than ObjC because there's less boxing overhead to small values. That should matter more than the overhead from more overflow checking.
    - mpweiher 4y ago
      > Swift<>ObjC bridging This is another commonly held belief that doesn't hold up to actual measurements. For an example, see part 2: https://blog.metaobject.com/2020/04/somewhat-less-lethargic-json-support_12.html https://blog.metaobject.com/2020/04/somewhat-less-lethargic-... All the pure Swift implementations are even slower than the bridged ones, and the bridged ones are slower than the most comically inefficient Objective-C one (using KVC, for example), which is slower than the reasonable Objective-C ones. > In particular Swift is more memory efficient than ObjC ... It's not. > ... because there's less boxing overhead to small values You would think, yes. I actually did think that as well. Because it really sounds plausible. So imagine my surprise when I measured some common cases for my book (Chapter 9) and it turned that even in the cases where I just knew™ that Swift would be faster, because of this very reason, it just wasn't. > That should matter more than the overhead from more overflow checking. Computers don't care what you think "should" be the case, and they cannot be argued into better performance due to plausible arguments and strongly held beliefs. You need to measure what actually is the case.
acdha 4y ago
What are you basing that on? It seems unlikely that they'd reverse the ongoing trend of improved performance, especially at a time when they're shedding backwards compatibility concerns with the migration to ARM removing the least-maintained apps.
klodolph 4y ago
Just to explain why Objective C code, in practice, is not especially fast: You generally make the choice between writing something in pure C, which gives you plenty of performance but little safety, or using Objective C classes and methods, which gives you plenty of safety but you're paying the price for dynamic dispatch (objc_msgSend) and pointer indirections all the time. Swift makes it easier to eliminate things like dynamic dispatch while still keeping the safety. So it should be normal and expected that a rewrite from Objective C to Swift would result in a speedup (and increase in code size).
- dilap 4y ago
  In practice would be what the resulting apps turn out like. In my experience, old-school ObjC iOS and Mac apps generally tended to be quite snappy. On the other hand, the new Swift hotness of Messages and Settings on macOS are noticably slower than what they're replacing. Of course I haven't done a comprehensive inventory, but I certainly don't have the general impression of things getting faster with Swift. (Are there examples of this?) My guess is any theoretical gains are generally swamped by the language culture of complex abstractions.
  - klodolph 4y ago
    Somebody rewrote an app in Swift -> the app is slower. Somebody rewrote a library in Swift -> the library is faster. There's a lot to talk about and unpack here. My experience is that people develop a different mindset when they do library development, because any code that they write will be code that they're forced to support for decades to come. You put bad code in an app and you can simply rip it out with the next revision, no questions asked. So you are much more likely to end up with questionable code in an app than in a library. I'm also old enough to remember not only the same complaints when people were rewriting apps into Objective C (lots of early Mac OS X apps were Carbon, including Finder), but when the same complaints were made about rewrites from assembler into C. Every decade your computer has a hundred times more computing power and your code takes 10x as much footprint, so you come out ahead, on average. It's just that any given year you might come out behind.
  - saagarjha 4y ago
lostlogin 4y ago
What has been getting slower for you?

hinkley 4y ago

I really should have started using Long Bets years ago. Ten years ago a “Tanya” told me she would never use an ebook to read literature. I’m pretty sure if I went to her house today I’d find 2. In fact I may be the only person I know who doesn’t own one (not wanting one and being fundamentally against them are two different things). That’s the most memorable but I’ve had these sorts of “over my dead body” conversations on a hundred topics over the years.

astrange 4y ago
I'm confused by the idea of searching someone's house for ebooks. Does that include PDFs?
- latexr 4y ago
  > confused by the idea of searching someone's house for ebooks. GP probably meant “ereader”.
eimrine 4y ago
Maybe Tanya reads a lot of PDF as kind of default format for all kinds of technical things and very common format for downloadable ebooks. AFAIK ebook readers are terrible in pdf rendering.
- deathanatos 4y ago
  > AFAIK ebook readers are terrible in pdf rendering. They're not really comparable formats. PDFs are documents rendered onto virtual paper: there is only so much a mobile device can do there, as a PDF is likely rendered as an 8½ by 11 or A4, which isn't going to be great on a tiny mobile screen. Bad tradeoffs between tiny text or pan-and-scan. eBooks, OTOH, are reflowable: ePub is "just" a ZIP of HTML¹. But the viewer can lay them out appropriately, so they can be formatted to fit your device, whether that's a tablet, a phone, or something else. IMO if you want to read something on a device, ePub > PDF for those reasons. PDF is good for print, & ensuring that what comes out of the printer has a shot at resembling the screen. (Though there are a good number of print settings to mess that up, too.) And, as a passably portable document format, if you're just doing short term viewing or something. ¹Plus a lot of other metadata that I'm eliding; it's a fair bit more complicated, of course.

deleted 4y ago

[deleted]