Apples to Apples, Part II

Apples to Apples, Part II(jessesquires.com)

90 points by poolpool 11 years ago | 13 comments

mpweiher 11 years ago |

Looking at the original article, it seems like he is comparing sorting an array of NSNumber objects in Objective-C with sorting an array of primitive integers in Swift.

The only really big surprise is that the latter actually used to be slower. Boggle.

JonathonW 11 years ago | |

It's worth noting that Swift Ints (and Arrays) aren't primitives; they're named types defined as structs in Swift code in the standard library, and have methods and can be extended like any other types in the library (see [1]). That's why the unoptimized case is slow, and why the author gets such a dramatic speedup from optimization-- the Swift optimizer (unlike the Objective C optimizer, which, thanks to ObjC's messaging system, has to keep method calls intact) can use techniques like method inlining to bring performance to a point close to that of a native int/plain C array.

Regardless, I'd still like to see a comparison with C++ (where method dispatch looks a lot like Swift and the optimizer should be able to do similar things) and plain C. Might have to try that this evening if I get bored.

1: https://developer.apple.com/library/prerelease/mac/documenta...

coob 11 years ago | | |

Likewise, it's also worth noting that since 10.7/iOS 5, NSNumbers can be tagged pointers rather than separately allocated objects.

tolmasky 11 years ago | |

Yeah, not to mention that NSMutableArray is not necessarily an array in Objective-C, see: http://ridiculousfish.com/blog/posts/array.html . It really seems like this benchmark is comparing different framework approaches more than any "core language speed" (similar to comparing stl::vector sort of ints in Objective-C++ to NSMutableArray sort of NSNumbers)

Just looking at the "std lib sort", what this might actually be testing off the top of my head is:

1. C-style-array access/write speed of "native arrays" vs. potentially hash-mappy access/write speed of array-like NSMutableArrays.

2. Direct integer comparison (a < b) vs -[NSNumber compare:] method dispatch speed.

3. I don't know how sorted() is implemented internally in Swift, but given that no comparison method is being passed in, you may also be comparing a fast internal int[] sort that directly compares ints to the speed of calling the NSComparisonResult lambda O(n lg n) times.

chucknelson 11 years ago | |

Can anyone explain the reasoning behind this difference? The article only mentions "In Objective-C, NSArray and NSNumber are used intentionally as the counterparts to Swift's Array and Int."

tolmasky 11 years ago | | |

I can't think of a good reason other than "I don't want to compare C-style sort with Swift because I want to talk about Objective-C". This is an incredibly poor benchmark in my opinion, since if you were dealing with a ton of ints in an Objective-C program you'd probably be dropping down to C or (in the case of ObjC++), C++. Back when Swift was slower and losing, I suppose it was eye opening that despite all this ObjC was still winning.

That's not to say that there isn't any insight here, I just think the much more powerful argument would be "look, in Swift we can get C-like speed without having to use icky primitive arrays". Which is actually a pretty powerful selling point (if its true, which we don't know, since C-style sorts aren't compared here).

free652 11 years ago | |

Swift is slower in the debug mode and faster with full optimizations. I don't know either language, but I think NSArray cannot store primitive types, so he used NSNumber object wrapper.

christoph 11 years ago | | |

Thats correct, you need wrap the primitive types when putting them in an array. Unless you use a C style array, but thats more hassle than it's worth generally.

ljosa 11 years ago |

Expected an Apple II; was disappointed.