Archive for February 3, 2016

Wednesday, February 3, 2016 [Tweets] [Favorites]

Swift Optimization Tips and Reference Counting

Apple (via @objctoswift):

If you need an array of reference types and the array does not need to be bridged to NSArray, use ContiguousArray instead of Array […]


Sometimes COW can introduce additional unexpected copies if the user is not careful. An example of this is attempting to perform mutation via object-reassignment in functions. In Swift, all parameters are passed in at +1, i.e. the parameters are retained before a callsite, and then are released at the end of the callee. This means that if one writes a function like the following […] a may be copied despite the version of a without one appended to it has no uses after append_one due to the assignment. This can be avoided through the usage of inout parameters […]


The compiler can only specialize generic code if the call site and the callee function are located in the same compilation unit. One trick that we can use to allow compiler to optimize the callee function is to write code that performs a type check in the same compilation unit as the callee function. The code behind the type check then re-dispatches the call to the generic function - but this time it has the type information.


Swift classes are always reference counted. The swift compiler inserts code that increments the reference count every time the object is accessed. For example, consider the problem of scanning a linked list that’s implemented using classes. Scanning the list is done by moving a reference from one node to the next: elem = Every time we move the reference swift will increment the reference count of the next object and decrement the reference count of the previous object. These reference count operations are expensive and unavoidable when using Swift classes. […] In performance-critical code you can use choose to use unmanaged references. The Unmanaged<T> structure allows developers to disable automatic reference counting for a specific reference.

Nick Hutchinson:

When compiling with ARC, method arguments often appear to be retained at the beginning of the method and released at the end. This retain/release pair seems superfluous, and contradicts the idea that ARC “produces the code you would have written anyway”. Nobody in those dark, pre-ARC days performed an extra retain/release on all method arguments just to be on the safe side, did they?

Dave Zarzycki:

When the compiler doesn’t know anything about the memory management behavior of a function or method (and this happens a lot), then the compiler must assume:

  1. That the function or method might completely rearrange or replace the entire object graph of the application (it probably won’t, but it could).
  2. That the caller might be manual reference counted code, and therefore the lifetime of passed in parameters is not realistically knowable.

Given #1 and #2; and given that ARC must never allow an object to be prematurely deallocated, then these two assumptions force the compiler to retain passed in objects more often than not.

Value vs. Reference in Swift

David Owens II:

This is a general concern of mine in Swift: how to actually know what has value vs. reference semantics.

Swift adds let and var, which fixes one problem. But there is no way to see what is a struct or a class, which adds another. It’s even more complicated in the context of the proposal to remove the “NS” prefix from Foundation class names.

Nate Cook:

As an example, the seemingly similar Set and CountedSet types produce different results from nearly identical code. Swift’s Set type has value semantics, so changes to a copy don’t affect the original Set instance […] CountedSet (née NSCountedSet), on the other hand, uses reference semantics, so changes to a copy of an instance. This is true whether the copy is an explicit one made via assignment or the implicit copy made when calling a function with CountedSet as a parameter. This example shows how nearly code nearly identical to the above produces very different results […]

Switching to HTTPS

Rainer Brockerhoff:

I’m using the invaluable checker for this, and already managed to get an A rating from the equally invaluable page.

Dave Winer:

The problem of requiring HTTPs in less than 140 chars: 1.Few benefits for blog-like sites, and 2. The costs are prohibitive.

There’s actually a #3 (sorry) -- 3. For sites where the owner is gone the costs are more than prohibitive. There’s no one to do the work.

Here’s a ten-minute podcast summarizing where we’re at with Google and Mozilla and HTTPS.

Kindle Update


Your Kindle will soon receive a free, over-the-air software update. Readers are always looking for their next favourite book, and this update provides new ways to help you easily find new books and new authors that you’re sure to love.


Our readers’ most-used settings—such as Aeroplane Mode and Device Sync—can now be found together with just one tap on your toolbar.

Kirk McElhearn:

All this looks like Amazon is desperately seeking to shore up ebook sales. Instead of letting you see just your books on the home screen, you have to pass through a vestibule displaying items to buy. Instead of only going to Amazon to search for books when you want, you’ll be exposed to more books each time you visit the home screen. You can naturally then see just your books, but it’s another tap, after your eye has been caught by the books at the bottom of the display.


If you go to advanced options in the updated Kindle software, you can disable the new opening screen entirely. That way when you turn on the Kindle, you see the old list format as before (but in the new, lighter typeface).

Update (2016-02-03): Jason Snell:

Fortunately, you can turn off recommendations, which I did. The fancy graphics disappear when you do this, but the entire interface has still been overhauled. There’s a new typeface that’s absolutely gorgeous on the high-resolution screen of my Kindle Voyage.