New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Runloop work distribution #42

Closed
ianolito opened this Issue Oct 15, 2014 · 1 comment

Comments

Projects
None yet
3 participants
@ianolito
Contributor

ianolito commented Oct 15, 2014

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

This comment has been minimized.

Show comment
Hide comment
@appleguy

appleguy Oct 15, 2014

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.

Contributor

appleguy commented Oct 15, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment