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 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.

You could mix Objective-C and Swift.

You can, but not as easily.

>> I switched back to my beloved Objective-C for the app I was developing.

Can you write the app in Swift (if there are advantages to doing so) and then write the image processing routines/library in C?

Yes, but I hate figuring out the bridging stuff when I can just use C directly in Objective-C.

The bridging is pretty straight forward no? You add a bridging header and put in all the headers you want to expose to swift and you are good to go.

Pretty straight forward, but there is zero friction when using Obj-C.

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).

Yeah, but the amount of code and API's for C make using Swift a bit of a pain when using the two.

What about using unsafe Array access if you want C style code?

Why does every Swift article use emojis in their code samples?

I imagine because Swift famously touted the ability to use emojis as identifiers.

Reading these things makes me hungry.

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.

The language supports emojis, and the point of example code is to be as concise and easy to understand as possible. Better than foobar.

Easy, our mobile devices screen width is limited. Emoji is the idea and it make learning not boring.

This article says ”Array can be toll-free bridged to an NSArray”, but is the reverse true, too?

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

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.

Good developers have battery empathy.

Good developers know when to use profilers.

thanks for your contribution to my job safety :p