Performance in Swift with Cocoa

Question

Since the cocoa libaries (Foundation, UIKit, CoreData etc.) are written in Objective-C and not converted to Swift (yet?) do we still get the performance benefits which Swift offers, when calling these cocoa libaries in Swift vs. using the libaries along with Objective-C (which has been the case until now)?

Answer 1

Erm...

The system frameworks are the system frameworks. They will perform the same regardless of which language they are called from.

Apple has millions of lines of code in their frameworks. (probably hundreds of millions of lines.) I doubt if they are going to be mass-converting all those frameworks to Swift. Instead, as they update and expand their frameworks, they will probably use Swift rather than Objective C where it's appropriate, and then provide interfaces for both languages. The transition in Apple's code is likely to be limited to new APIs and/or APIs where they are doing a major overhaul for some other reason.

When you look at the performance of an app, it usually boils down to a small amount of code that is the bottleneck and takes the bulk of the time. Optimizing other parts of your program have very little effect.

If your program winds up spending most of it's time in application frameworks, then it doesn't matter if it's written in Objective C, Swift, native assembler, or Java.

Personally, I am very skeptical of Apple's claims of huge performance benefits from Swift. I suspect that their comparisons deliberately picked problems that have very bad performance characteristics when written in "pure" Objective-C (ignoring the fact that Objective-C is a true superset of C, and you can always write C code in an Objective-C program.)

I am an old assembler jockey, and a C programmer after that. When I do application design, I avoid creating objects that represent tiny atoms of data, minimize memory allocations in tight loops, and will even sometimes write critical code using C functions rather than Objective-C method calls. I already optimize my design and implementation with an awareness of what slows programs down. I would hazard a bet that with this approach, the difference between Swift and Objective-C code is small. If we have less control in Swift over what is an object and what is a simple array of scalar values, I would expect careful coding would still yield better performance with a mix of C and Objective-C.

Another point is that usually your algorithms make much more difference than your implementation. If you use a bubble sort on a million records, it's gonna be dog-slow even if you write the slickest, most highly optimized implementation of a bubble sort.

Example:

Our company has a Mac program, FractalWorks, (link) in the Mac App store. It is a very high performance fractal renderer. Internally, it allocates a block of memory to store results, and then uses carefully crafted C code to do the number-crunching. It is multi-threaded, and keeps every core on your Mac "maxed out" until the calculations are done. When possible, it also uses knowledge of the geometry of Mandelbrot and Julia sets to use a "boundary following" algorithm, and traces the outside of regions that have the same "iteration value", and then flood-fills the whole region, thus often saving millions or even billions of expensive floating-point calculations. The first part, using memory buffers and C code to calculate results, is implementation optimization. The second bit, the boundary following algorithm, is an algorithm optimization, and for problems where it's a good fit, it can reduce the number of calculations by 5X or even 10X.