5 ms·

It's good that they are making these breaking changes now. I like the language and the changes they are making. The next focus should be on performance in my v

It's good that they are making these breaking changes now. I like the language and the changes they are making. The next focus should be on performance in my view. String processing in particular is too slow to be usable for server-side tasks. Also, I wonder what to do with Foundation in the long run. It's huge but its design is extremely antiquated. At some point Apple will have to shed that past where URL manipulation and file system operations are methods on a string class.

stepanhruda 11y ago
Foundation is being completely rewritten in Swift in https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-foundation The first proposal for bringing Foundation APIs to this decade has already been accepted for Swift 3: https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md https://github.com/apple/swift-evolution/blob/master/proposa...
- fauigerzigerk 11y ago
  These are small adaptations to Swift's semantics and naming guidelines. There is nothing in these documents that hints at the sort of root and branch redesign of the APIs that I think is necessary. Cocoa as a whole is obsolete and needs to be replaced by something better. It is the epitome of everything that is wrong with 1980s/1990s style object oriented design: Huge classes, massive coupling, very little cohesion.
  - stevetrewick 11y ago
    While it's true that "the implementation of [all but 3 of] these types will use the existing reference type API", this means (AIUI) that there will now be a swifty shim between swift and Foundation rather than the types being bridged directly. I would expect that would make the job of replacing Foundation with something appropriately modern easier in several dimensions.
  - kartickv 11y ago
    What are some examples of "huge classes, massive coupling and very little cohesion"? Barring a few example like NSString UIKit Additions, I thought it's well thought out.
    - fauigerzigerk 11y ago
      One of the things that permeates the API is a complete lack of separation of data structures and IO. For instance, NSData, NSDictionary and NSArray all have methods for loading and storing their contents from/to a location specified as a URL. NSURL deals with all sorts of stuff like bookmarks, cached resources and file system properties.
      - stepanhruda 11y ago
        E.g. Swift standard library already replaces dictionaries and arrays without adding similar bloat. I think/hope they want feature parity first and then will start moving towards what you propose.
      - kartickv 11y ago
        I see your point. Thanks for explaining.
austinz 11y ago
Regarding strings... I briefly ran the code sample you graciously provided me with a month ago through the profiler (https://gist.github.com/austinzheng/d6c674780a58cb63832c4df3f809e683 https://gist.github.com/austinzheng/d6c674780a58cb63832c4df3...). Long story short, it looks like the reflection machinery in the standard library is improperly being used to construct String instances. Doing so, while probably not sufficient to account for the entirety of the awful performance, is probably quite expensive. This looks like a bug and I'll try to dig deeper into it this week. Swift also badly needs a native version of NSCharacterSet, even if only for programmer ergonomics. The developer in charge of the standard library has mentioned that that team intends on redesigning the String API in the near future; this should provide an opportunity to reexamine the performance implications of the current implementations.
- fauigerzigerk 11y ago
  That's excellent news. Thanks a lot!
  - austinz 11y ago
    After a bit more investigation, I found that if you replace the following code: result.append(begin == eos ? "" : String(cs[begin..<end.successor()])) with this: if begin == eos { result.append("") } else if let str = String(cs[begin..<end.successor()]) { result.append(str) } runtime goes down from ~3 seconds to ~2.2 seconds. This is due to a rather insidious API design decision: init?(_ view: String.UTF16View) constructs a string out of a UTF16 view, but it can fail. If used in a context where its type is inferred to be non-nullable, the following generic reflection-related init is used instead: init<T>(_ instance: T) I'm going to bring this up on the list and see if there are better ways of doing things. As far as I can tell most of the rest of the time is spent in the Swift native Unicode --> UTF16 decoding machinery, and NSCharacterSet.
    - fauigerzigerk 11y ago
      I'm seeing a 23% increase in running time after making that same change. Strange. That's with Xcode 7.3.1 (7D1014)
galad87 11y ago
You can already do URL manipulations with NSURL and NSURLComponent, it took time but almost all file system methods can take an NSURL now instead of a NSString.

stepanhruda 11y ago

Foundation is being completely rewritten in Swift in https://github.com/apple/swift-corelibs-foundation https://github.com/apple/swift-corelibs-foundation The first proposal for bringing Foundation APIs to this decade has already been accepted for Swift 3: https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md https://github.com/apple/swift-evolution/blob/master/proposa...

fauigerzigerk 11y ago
These are small adaptations to Swift's semantics and naming guidelines. There is nothing in these documents that hints at the sort of root and branch redesign of the APIs that I think is necessary. Cocoa as a whole is obsolete and needs to be replaced by something better. It is the epitome of everything that is wrong with 1980s/1990s style object oriented design: Huge classes, massive coupling, very little cohesion.
- stevetrewick 11y ago
  While it's true that "the implementation of [all but 3 of] these types will use the existing reference type API", this means (AIUI) that there will now be a swifty shim between swift and Foundation rather than the types being bridged directly. I would expect that would make the job of replacing Foundation with something appropriately modern easier in several dimensions.
- kartickv 11y ago
  What are some examples of "huge classes, massive coupling and very little cohesion"? Barring a few example like NSString UIKit Additions, I thought it's well thought out.
  - fauigerzigerk 11y ago
    One of the things that permeates the API is a complete lack of separation of data structures and IO. For instance, NSData, NSDictionary and NSArray all have methods for loading and storing their contents from/to a location specified as a URL. NSURL deals with all sorts of stuff like bookmarks, cached resources and file system properties.
    - stepanhruda 11y ago
      E.g. Swift standard library already replaces dictionaries and arrays without adding similar bloat. I think/hope they want feature parity first and then will start moving towards what you propose.
    - kartickv 11y ago
      I see your point. Thanks for explaining.

austinz 11y ago

Regarding strings... I briefly ran the code sample you graciously provided me with a month ago through the profiler (https://gist.github.com/austinzheng/d6c674780a58cb63832c4df3f809e683 https://gist.github.com/austinzheng/d6c674780a58cb63832c4df3...). Long story short, it looks like the reflection machinery in the standard library is improperly being used to construct String instances. Doing so, while probably not sufficient to account for the entirety of the awful performance, is probably quite expensive. This looks like a bug and I'll try to dig deeper into it this week. Swift also badly needs a native version of NSCharacterSet, even if only for programmer ergonomics. The developer in charge of the standard library has mentioned that that team intends on redesigning the String API in the near future; this should provide an opportunity to reexamine the performance implications of the current implementations.

fauigerzigerk 11y ago
That's excellent news. Thanks a lot!
- austinz 11y ago
  After a bit more investigation, I found that if you replace the following code: result.append(begin == eos ? "" : String(cs[begin..<end.successor()])) with this: if begin == eos { result.append("") } else if let str = String(cs[begin..<end.successor()]) { result.append(str) } runtime goes down from ~3 seconds to ~2.2 seconds. This is due to a rather insidious API design decision: init?(_ view: String.UTF16View) constructs a string out of a UTF16 view, but it can fail. If used in a context where its type is inferred to be non-nullable, the following generic reflection-related init is used instead: init<T>(_ instance: T) I'm going to bring this up on the list and see if there are better ways of doing things. As far as I can tell most of the rest of the time is spent in the Swift native Unicode --> UTF16 decoding machinery, and NSCharacterSet.
  - fauigerzigerk 11y ago
    I'm seeing a 23% increase in running time after making that same change. Strange. That's with Xcode 7.3.1 (7D1014)

galad87 11y ago

You can already do URL manipulations with NSURL and NSURLComponent, it took time but almost all file system methods can take an NSURL now instead of a NSString.