3 ms·

That's pretty clean. It is also rather inefficient. I think dropFirst copies the sequence and then the result is copied again to create a String and then finall

That's pretty clean. It is also rather inefficient. I think dropFirst copies the sequence and then the result is copied again to create a String and then finally it gets parsed into a Float. No problem for one Float, but parsing a largish CSV file like that may be a different matter. At least I think that's what's happening. I'm not 100% sure.

mikeash 11y ago
Nope, it's all just pointer games. I just tested it here and inspected the guts in the debugger. My initial string containing "123456789" contains a pointer internally to 0x000000010006d326 which contains that data. The result of .characters contains that same pointer. The result of .dropFirst(1) contains 0x000000010006d327 and the result of turning it back into a string still contains 0x000000010006d327. That's the great thing about abstract APIs and immutable data types, you rarely need to actually copy anything.
- fauigerzigerk 11y ago
  Maybe it's a short string optimization in this case, because the docs say that dropFirst is O(n) https://developer.apple.com/library/prerelease/ios/documentation/Swift/Reference/Swift_CollectionType_Protocol/index.html https://developer.apple.com/library/prerelease/ios/documenta... Or they have optimized it after writing the docs. In any event, there's a lot more going on than what is necessary to parse a float. But I guess that's OK if the goal is to have a clean and consistent high level API.
  - mikeash 11y ago
    In that context, n is the number of items being dropped, not the length of the collection.
    - fauigerzigerk 11y ago
      I wonder what makes it so slow then. I'm looking forward to the day when we can look at the source code :)
      - mikeash 11y ago
        Where are you getting that it's slow?
        fauigerzigerk 11y ago
        In my own little ad-hoc micro benchmark it is. That's why I suspected that there was copying going on, but there could be so many other reasons for it that it was probably a pointless exercise in the first place. [Edit] And I mean relatively slow (4x the C++ code), not absysmally slow. Not a big deal.
        mikeash 11y ago
        Gotcha. Do you have optimizations on? If so, I'd guess it's just the overhead of the extra indirection, plus dropFirst does have to examine that first little bit of data to determine the grapheme cluster boundaries.
        fauigerzigerk 11y ago
        Yes I've done a release build.

mikeash 11y ago

Nope, it's all just pointer games. I just tested it here and inspected the guts in the debugger. My initial string containing "123456789" contains a pointer internally to 0x000000010006d326 which contains that data. The result of .characters contains that same pointer. The result of .dropFirst(1) contains 0x000000010006d327 and the result of turning it back into a string still contains 0x000000010006d327. That's the great thing about abstract APIs and immutable data types, you rarely need to actually copy anything.

fauigerzigerk 11y ago
Maybe it's a short string optimization in this case, because the docs say that dropFirst is O(n) https://developer.apple.com/library/prerelease/ios/documentation/Swift/Reference/Swift_CollectionType_Protocol/index.html https://developer.apple.com/library/prerelease/ios/documenta... Or they have optimized it after writing the docs. In any event, there's a lot more going on than what is necessary to parse a float. But I guess that's OK if the goal is to have a clean and consistent high level API.
- mikeash 11y ago
  In that context, n is the number of items being dropped, not the length of the collection.
  - fauigerzigerk 11y ago
    I wonder what makes it so slow then. I'm looking forward to the day when we can look at the source code :)
    - mikeash 11y ago
      Where are you getting that it's slow?
      - fauigerzigerk 11y ago
        In my own little ad-hoc micro benchmark it is. That's why I suspected that there was copying going on, but there could be so many other reasons for it that it was probably a pointless exercise in the first place. [Edit] And I mean relatively slow (4x the C++ code), not absysmally slow. Not a big deal.
        mikeash 11y ago
        Gotcha. Do you have optimizations on? If so, I'd guess it's just the overhead of the extra indirection, plus dropFirst does have to examine that first little bit of data to determine the grapheme cluster boundaries.
        fauigerzigerk 11y ago
        Yes I've done a release build.