

Auto Layout Performance on iOS - Garthex
http://floriankugler.com/blog/2013/4/21/auto-layout-performance-on-ios

======
skue
I wish this article spent more time discussing how autolayout is implemented
in the real-life example, and less time talking about absurd situations such
as using autolayout with a thousand subviews.

We are given no info about what constraints were used and whether the view was
created in code or IB. For all we know, maybe all they needed was an extra
constraint or two they to speed things up. Diving into how changing individual
constraints affects overall performance would be interesting. It would be nice
if Instruments had a template for inspecting autolayout performance (or does
it? I haven't looked and not by my desktop).

Also, the numbers without autolayout still aren't great (hopefully that was
tested on low end hardware?). I wonder why the OP didn't just pre-render the
next view in the background, since he has the luxury of knowing that users
will page through views in a linear fashion.

~~~
the_french
I don't know much about how autolayout works, but wouldn't it be possible to
solve some of the constraints at compile time? e.g when you compile your app
for iphone it could try and solve as much as possible considering the known
screen size, etc..

~~~
gdubs
The idea is that it accounts for variations in things like string length for
labels, image sizes and proportions -- things not always known at compile
time.

But, for layouts where that's not the case, a compile time constraint builder
would indeed be nice.

------
evadne
Practicing latency hiding techniques might be useful here. Try grabbing a
first generation iPhone and scroll really fast in Safari, for example — you’ll
see a checker grid underneath the actual content. iOS interaction emphasizes
movement and fluidity over visual clarity or pixel perfectness; while it is
actually acceptable to drop granularity it is usually frowned upon to drop
frames. Our Choice (the famous Al Gore book on iOS by Push Pop Press) does the
same thing. iBooks does the same thing (PDF only; its ePUB part just chokes).
Even GoodReader does the same thing.

Several general strategies off the back of my hand: a) precompute images in
the background, store and decode the important bits on the fly; b) use proxy
images unless the card is visible; c) a combination of both. Sounds like a fun
problem (for solving it the first time).

On layout — Autolayout is slow, period. On a collection view with square cells
of identical sizes, autolayout takes over five seconds to make up its mind.
(This is from a random iPhone 4S.) If your design is not super flexible, it
might make sense to set up a few styles up front and reuse them again and
again. Even drawing unstyled text into framebuffers is heavy if you do it
often on dynamically generated content. (For example, 72 small labels for a
scrolling date picker chokes at <30FPS.) Sometimes it’s better to design the
issue away. Even a well-written piece of software may look awkward and work
clumsily when it resizes during rotation while a square thing will generally
work. The last ditch is to crossfade, but I digress.

The last thing I think is very relevant: layout taking a long time is actually
also not a big deal if you only do the initial layout for two or three views
you end up reusing. Small, frequent memory allocation (and drawing) during
human interaction kills the joy. Hopefully, if you’re using an
UIPageViewController, you’re also reusing the view controllers and its views.

Side note: I have not seen a great way to cancel work halfway done or is no
longer necessary on iOS at the library / framework level. NSOperation has
cancellation support which is basically twiddling glorified (hopefully)
thread-safe boolean flags that get checked periodically. Sometimes people
decide to throw the results away in the completion handler.

------
rmrfrmrf
More or less what I expected -- I thought it was common knowledge that
anything code-related with "auto" in it is going to have some significant
overhead, as you can pretty much guarantee that there is a ton of looping
going on.

------
phil
Those look like parabolas, which implies that there's something O(n^2) going
on. Since autolayout has to evaluate each constraint against the other
constraints, this shouldn't be too surprising.

Like other commenters, I find the 1,000 subview test runs pretty silly. (Pro
tip: if you need to put thousands of things on the screen, you don't want to
give each one its own view. They aren't that light no matter how you lay them
out).

This stuff is pretty clearly optimized for use with a handful to a few dozen
views. It would be great to see a performance comparison for that range.

------
coldcode
I've found auto-layout to be less than useful much of the time, often you are
left with puzzlement as to what's wrong, leading to turning it off and doing
something else.

