• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

Runtime-Run Loops

Page history last edited by Charles Jolley 14 years, 2 months ago
  • A RunLoop gives you the ability to control when your code is run.
    • Built-in browser mechanisms such as setTimeout() are not reliable since they can be delayed or overlap causing performance problems
    • The RunLoop is used extensively in SproutCore to defer execution of some key events such as firing observers and updating the browser UI until your code is finished.  This allows your code to run much faster.
    • You should learn to effectively use the RunLoop to defer long running code yourself to improve performance.  As well as to control the order your code will run in.
  • Every time your code is run by the web browser, it should be wrapped in a call to the RunLoop to begin and end the loop.  This will give the RunLoop a chance to setup any needed buffers and then execute any deferred actions later on.
    • Anytime you use the built-in SproutCore event system, the RunLoop is called automatically.  
    • Unless you listen for events in the browser manually, you will not usually need to start/end runloops yourself.
  • The idea is that whenever an event occurs, a RunLoop begins, your event handler code runs [this should be fast and simple], then the RunLoop ends.  
    • At this point, the RunLoop will fire any observers and update any bindings triggered by changes in your event handler code.  Timers and invokeOnce() handlers may also execute at this time.
    • After these observers finish, the RunLoop to check to see if any new observers or bindings have been triggered and, if so, execute them as well. 
    • This cycle repeats until there are no observers, bindings, or pending timers remaining to fire.
    • Then the code exits.
  • Because of this timing behavior, this allows changes in your app to propagate in "waves".  
    • Wave 1: your event handler code runs
    • Wave 2: bindings and observers triggered by your event handler code runs
    • Wave 3: bindings and observers triggered by observer code runs
    • Repeat until nothing is left to fire

 

Deferring Expensive Code

 

A well designed app should rely heavily on this deferred updating mechanism to keep your code fast.  Write short simple methods that update only a few other properties.  If you might need to recompute some values that might be expensive, consider using invokeOnce() to defer that execution til the end of the runloop.  This way if your property changes several times you won't have to run the expensive code.

 

Deferring Code Until Later

 

  • Use invokeLater() instead of setTimeout()
  • invokeLater() uses a single dispatch queue to execute code which is both faster and more reliable than setting a bunch of timeouts.
  • invokeLater() is intended to be suitable for use as part of an animation layer.  You can invokeLater() a bunch of separate items and they will generally execute in order and on time.

 

Testing RunLoop Code

 

  • Note that unit tests do NOT start/end a RunLoop automatically . This allows you to manually start/end runloops as needed to do a test

 

 

 

Comments (0)

You don't have permission to comment on this page.