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.
But, for layouts where that's not the case, a compile time constraint builder would indeed be nice.
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.
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.