Auto Layout Performance on iOS — Florian Kugler

Auto Layout made its first appearance with Mac OS X Lion. One year later Apple introduced it on iOS 6 as the new and preferred way of laying out views (Auto Layout is enabled by default). It's main advantage is that it allows for more flexible layouts when dealing with multiple screen sizes, interface orientations and languages.

The project I'm currently working on with Chris Eidhof uses Auto Layout for most of its interface layout. However, as the project was nearing its final stages and we started to look more into performance issues, the question arose how Auto Layout actually impacts performance. We found ourselves disabling Auto Layout in more and more places, because it had a significant performance hit.

Searching for information about the performance characteristics of Auto Layout didn't bring up anything useful. Therefore I started my own Auto Layout profiling experiment and can now share some useful information with you in order to be able to make good decisions of when to use or not to use this technology.

Auto Layout Performance in Theory

With Auto Layout you specify a series of explicit and implicit constraints for each view. Explicit constraints are the ones you create in Interface Builder or in code ([NSLayoutConstraint constraintWith...]) like width, height, spacing or alignment constraints. Implicit constraints are the constraints which are created from properties like the content hugging priority and compression resistance priority.

Each constraint is basically just a simple linear equation. All constraints together define a system of linear equations which unambiguously describe the layout, given that you have set up the constraints correctly. In order to translate the constraints into frames, Auto Layout has to solve this system of linear equations. Therefore Auto Layout necessarily presents a performance hit compared to setting the frames of the views yourself. The question is just: how much time does it take?

We know that constraint satisfaction problems as Auto Layout are decision problem of polynomial complexity (Auto Layout uses the Cassowary constraint solver). That means that the amount of time it takes to solve the constraint system increases disproportionally relative to the number of constraints involved. We will be able to clearly see this characteristic in the measurements below.

The polynomial complexity of the Auto Layout algorithm tells us already, that it probably can deal with a small number of views, but will run into serious performance problems for a large number of views. But what is "small", and what is "large"? Furthermore the interdependency of the constraints also plays a role in the time it takes to calculate the layout, as we will see below.

Profiling Auto Layout

In order to measure the performance hit of Auto Layout I created a small and ugly test app (check it on GitHub) which layouts and draws an arbitrary number of views in different ways:

• Each view is laid out relative to the same super view
• Each view is laid out relative to a sibling
• Each view is nested into the previous one

All tests were performed on an iPad mini (1st generation, for future reference...) and profiled with Instruments. For each attempt I entered the number of views to render and then chose the way the should be rendered by tapping one of the buttons. The subsequent work done to accomplish this task was measured with the time profiling instrument.