Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Runloop work distribution #42
In the NSLondon video, Scott talks about runloop work distribution. Unless I’m missing something here, this optimization does not seem to be implemented right now. I was wondering if you were still planning on adding this feature to the framework.
I understand this strategy applies to expensive operations that have to run on the main thread, such as creating views and adding them to the hierarchy. What about the opposite operations (removing from hierarchy and deallocating views)? Does those benefit from being distributed as well?
Good question. This is one of many things we have implemented, but are not in the 1.0 version of the public framework. Reasons include:
This feature is an example of one that needs to have a carefully thought-through API to make it useful and intuitive. Some mechanism of determining the "block size" (how much work to do per turn of the runloop), and supporting a wide variety of operations, is important but non-trivial. It's a solvable problem but would primarily help only the most complex apps—probably "top 5%" in terms of rendering complexity / hierarchy depth.
The technique does work equally well for removing subviews / sublayers and deallocating views / layers as it does for adding / creating them, but that degree of general applicability is one of the key qualities of the approach that makes it a little difficult to settle on the best API.
This is a great question / discussion for the Paper Engineering Community group if you want to cross-post the question there (I'll add this comment to the thread), particularly if you have further questions, which I'd be happy to answer.