Skip to content
This repository has been archived by the owner on Feb 2, 2023. It is now read-only.

Runloop work distribution #42

Closed
ianolito opened this issue Oct 15, 2014 · 2 comments
Closed

Runloop work distribution #42

ianolito opened this issue Oct 15, 2014 · 2 comments

Comments

@ianolito
Copy link
Contributor

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?

@appleguy
Copy link
Contributor

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:

  1. Unknown demand for such advanced optimizations make it hard to gauge value of spending time making those features available, vs investing in documentation, sample code, or other framework features.
  2. Limited time (currently all the maintainers of ASDK are working on Instagram, which doesn't yet use ASDK, so seeing demand / interest in the framework will help us justify more time).

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.

@shLuckySeven
Copy link

wow!nice

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants