Very fascinating stuff, also follow the link at the bottom of the article towards another explanation with visuals how arrays are structured.
Honestly I never run into performance problems since the volume of data I work with is either really huge and done in a C or C++-based library or so small I would never think about array performance.
On the contrary, developing a good intuition about stuff like this so you get it right the first time is a big time saver in the long run. Especially when it's no extra code to do the better thing to begin with.
Optimization makes a huge difference with arrays in Swift. The following took 2.37 seconds (!) on my machine un-optimized:
var bytes = [UInt8](count: 16_737_732, reapeatedValue: 0)
This was slow enough to block my UI (spinning pizza) -- so I ran it on a background thead!. Turn on optimization and it took a more reasonable 0.0165 seconds. BTW, took C's memset only 0.00827 seconds on the same machine.
I switched back to my beloved Objective-C for the app I was developing. Won't be using Swift for low-level image processing.
You say 'beloved Objective-C'. Sorry if this is really off topic, but is objc_msgsend (the whole late-binding thing) or anything else about Objective-C particularly appealing? Maybe the decent unoptimized speeds or the fact that you can use plain C whenever?
I love C because I do a lot of low-level programming and I feel closer to the machine with C. For higher level UI stuff I like the Smalltalk extensions to C and Obj-C's dynamic nature and the fact that I can use C (and C++ directly).
Also I have been programming the Mac for a long time and I have a lot of mental investment in Objective-C.
OTOH, I do like the functional, strongly-type features of Swift, but like any higher level language I feel more removed from the machine. That's the price for abstraction.
I found that when doing lots of array code that needs to be fast, you cannot rely on the high-level abstractions of normal Swift. But even while staying in Swift there are API's to drop down to, lower levels of array manipulation etc. where you get the speed of raw C (independent of your optimisation settings).
I prefer Swift for general purpose iOS development but I have one app that leans heavily on a lot of C++ DSP code and that one is likely to stay ObjC just because interfacing ObjC & C++ is so painless.
26 comments
[ 3.6 ms ] story [ 89.6 ms ] threadHonestly I never run into performance problems since the volume of data I work with is either really huge and done in a C or C++-based library or so small I would never think about array performance.
Good developers have battery empathy.
I think it’s because that’s the style of Apple’s own (excellent) Swift Programming Language book.
I think it does look nicer than the traditional characters used in these kinds of things.
I switched back to my beloved Objective-C for the app I was developing. Won't be using Swift for low-level image processing.
Can you write the app in Swift (if there are advantages to doing so) and then write the image processing routines/library in C?
Also I have been programming the Mac for a long time and I have a lot of mental investment in Objective-C.
OTOH, I do like the functional, strongly-type features of Swift, but like any higher level language I feel more removed from the machine. That's the price for abstraction.
https://developer.apple.com/library/content/documentation/Sw... says the two are bridged, but doesn’t mention whether that is toll-free.
If that is toll-free, users of Array, just as users of NSArray, should be aware that indexing in them can be O(log n). See http://ridiculousfish.com/blog/posts/array.html