Developer Journal: Memory Optimization

written by Tyler Keating

The next release candidate for 1.11.0 will be out very shortly, but I thought it best to post a brief update on the past week’s work as this week saw a concentrated effort on core optimization.

First we took another look at the use of arguments lists throughout the framework and found several more occurrences of it being accessed in an inefficient manner. Depending on the browser, accessing arguments in such a way that causes it to be allocated can be up to 80% slower and so it’s really good to have these all fixed.

The other piece of optimization work undertaken has been much more difficult. We’ve been looking into high frequency event handling, such as during touch dragging or mouse moving, with an eye towards managing memory better. Since SproutCore already does as much as possible to avoid touching the DOM, the largest issue that affects the “fluidity” of the user interface is JavaScript garbage collection. If the heap is filling up rapidly with unreferenced objects, the JavaScript engine will be forced to collect them more frequently and the act of collecting them will take longer. Since we have no control over when garbage collection occurs, for example we can’t prevent it from happening in the middle of a transition, the best we can do is to reduce its impact. So essentially, our goal is to not allocate any additional memory during high frequency events and our primary means to that goal is through shared Object re-use.

As I mentioned, this has been very difficult, but we’ve been steadily identifying and replacing Objects (hashes) and Arrays with single shared versions wherever possible. This includes some key high touch areas in SC.View’s layout code and SC.Event’s architecture. In fact, a major refactor of SC.Event was completed in order to re-use a single shared normalized event instance per event type. This means that whereas previously each event (e.g. touchmove) would allocate a new normalized SC.Event each time, it now re-uses just the one. The affect of all of this work is a slightly flatter memory profile with fewer and smaller saw-tooth garbage collection drops in it. It’s not perfect yet and it’s likely impossible to not allocate a bit of memory on each event, but some exciting progress is being made.

Lastly, a bit more internal debugging code was moved into debug-mode only. This means that the code will not be included in production builds, thus reducing the overall size of the production JavaScript by a tiny bit. A minor optimization, but one none-the-less.

Developer Journal

written by Tyler Keating

Since there has been so much activity in SproutCore lately in the run up to 1.11.0, I thought it would be best to start a more regular update on the changes occurring in master. While we occasionally highlight a specific new feature in depth through a “Dispatches from the Edge” post, there are actually hundreds of small, yet interesting, changes occurring weekly that aren’t large enough to warrant their own post. It’s my hope to capture these changes in a weekly to bi-weekly developer update. So let’s begin with the last couple of weeks (Note: no changes are final).

Touchy Mice

If you own an Apple Magic Mouse, you may have found some web apps difficult to use. A notable public example of this problem was in the Google Maps app. When you released your finger after dragging the map around, the extra mouse wheel events that were sent as your finger was lifted caused the map to zoom in and out rapidly. Now I believe Google has fixed that problem with their app and we have as well for SproutCore’s SC.SliderView and SC.ScrollView, both of which use mouse wheel events. To prevent the extra mouse wheel events that can occur on click or release from triggering the control, we ignore any mouse wheel events that fire while the mouse is pressed up until 250ms after the mouse up event. Depending on how adept your users are with their mice clicks, the result may be a huge improvement or barely perceptible, but even as small a change as it is to prevent scrolling jiggle on mouse click, it’s just one more brick in the incredible user experience wall that we’re trying to build with SproutCore.

Performance

We’ve been working diligently on SC.ScrollView performance (more on that later), but in the process we’ve implemented some other performance improvements.

We fixed a problem with excessive layout updates for certain types of views. If a view used viewDidResize to check for size changes and then make further adjustments to its position, the adjustments to its position would have appeared as further changes to its size. In particular, SC.PickerPane suffered from this, since it re-positions itself whenever its size changes.

Speaking of SC.PickerPane, this one got a performance scrub down. You may not have been aware, but SC.PickerPane now has some special code enabling it to appear within scrollable content and move correctly when the content scrolls. It’s a really nice advanced feature, but there were a couple of issues hampering the performance of it. The first was that the scroll view observers were too greedy observing offsets of the scroll view for changes and repositioning on each change. What this meant was that an SC.PickerPane could reposition itself up to 6 times in a single run loop as the content of the scroll view changed. Instead, the proper pattern for observing multiple properties (or noisy properties) is to filter the input through an invokeX (i.e. so even though 6 calls to the observer function may occur, we only call positionPane once). Additionally, we no longer observe the offsets if the scroll view can’t even scroll and finally, there is a bug fix in there too. When the picker’s anchor gets moved on its own, we ensure that the anchor is in its new position before we re-position.

One of the most important classes within SproutCore has been sped up a bit too. SC.State had two observes helper functions used to be notified when its enteredSubstates and currentSubstates arrays changed. Since these arrays are modified by the owner statechart, the observers needed to be chained enumerable observers. However, this resulted in slower object initialization for each state object and excess observer firing as the entered and current substates change. Instead, we simply notify the target state directly each time that the owning statechart makes a change to its enteredSubstates and currentSubstates. This one has has a couple benchmarks to site:

Benchmarks:

  • initStatechart in unit tests: ~21ms to ~13ms (~38% faster)
  • initStatechart in large application: ~81ms to ~51ms (~37% faster)

While a reduction of 30ms in a, generally once run, method isn’t much to write home about, we are relentless in shaving every possible millisecond that we can. More notably, we’ve recently made some serious performance improvements to the core SC methods: SC.mixin, SC.supplement as well as to SC.Function.enhance. SC.mixin and SC.supplement iterated the arguments object to insert a boolean flag to pass to a private function that then iterated the arguments again in order to remove the flag argument, which is totally unnecessary. Instead, SC.mixin and SC.supplement iterate the arguments once and pass the new Array to the private function, removing the need for a second iteration.

More importantly though, is that these three areas no longer access the arguments object to copy it, which required the browser to instantiate it and is costly. Instead, we now do a fast copy (similar to this: http://jsperf.com/closure-with-arguments) without instantiating the arguments object. By doing a fast copy of arguments these functions are now optimizable by V8.

Benchmark: SC.mixin & SC.supplement ~ 58% faster

Also,SC.RenderContext‘s setStyle method was updated so that it could be optimized for V8 as well.

SC.ScrollView and SC.MenuScrollView Refactor

This one will actually get its own blog post. For now, I just wanted to mention that these views have seen massive refactoring. The purpose of the changes has been to simplify the logic, which had gotten fairly unruly, but more importantly to grind and grind on the little details so that scrolling and scaling should feel as good and as natural as possible. We’ll post an in-depth on SC.ScrollView in the next couple weeks.

SC.MenuPane Tidy

We fixed SC.MenuPane automatic resizing to fit within the window. The positioning code used in SC.PickerPane failed to apply adjustments to the width or height of the pane, which had been calculated in order to fit long menus within the window. This included improving the menu positioning code to respect the value of windowPadding and fixing a problem where the items array was not observed for content changes if it was set on create.

We removed an unnecessary layout change in createChildViews, which also meant that creating a menu pane as a singleton (i.e. with no run loop) would throw invokeOnce warnings.

WARNING We removed the SC.MenuPane.VERTICAL_OFFSET property. SC.PickerPane already has a provision for offsetting panes from the window’s edges, windowPadding, and that is the property that is being used now.

General fixes and changes

Finally, there are always a large number of little changes. Here are some from the last few weeks.

  • Removed an extra call to SC.RootResponder‘s computeWindowSize each time that a pane is appended. This is unnecessary, since the root responder recomputes its window size property whenever the window actually resizes.
  • Improved the default styling of overlay scroller views. Making them look more like natural overlay scrollers in OS X and making them more visible against dark backgrounds.
  • Improved the view management of SC.ContainerView a bit. If contentView is set as an uninstantiated view class, it will instantiated correctly (you should set nowShowing though normally).
  • Fixed SC.ObserverSet to pass the given context to the observer method. SC.ObserverSet.prototype.add() accepts a third argument, context, but it did not actually pass it along to the observer method.
  • Improved SC.MenuItemView handling of submenus. Previously if the item’s submenu was visible and the mouse exited back onto the menu item view, it tried to re-append the same submenu. Instead, it now checks to see if its submenu is already attached before attempting to enter it again.
  • Fixed a bug in SC.ContainerView‘s override of set so that it may be chainable.
  • Did you know you can cancel animations created with animate in place? This includes transform transitions whose in place value is represented as a 4×4 matrix that must be decomposed to find the current value for translate, scale and rotate in the three planes. We’re still working on rotation around the X and Y axis, but all other transforms can be cancelled. A demo on this will come later.

I apologize that this post is quite long, if it actually included all the work in the scroll and scroller views it would be three times longer, but as you can see, there is a lot going on. I hope to keep these posts much shorter from now on by keeping them more regular.

Dispatches From the Edge: Polymorphic Records

written by Tyler Keating

We have good news for anyone using the experimental polymorphism framework from within SproutCore. You’ll be glad to know that it has now made its way into the official datastore framework as part of SC.Record. If you have been using this framework, you’ll be even more glad to learn that polymorphic records are now significantly faster and more memory efficient. As well, this change includes a critical bug fix that resulted in polymorphic records getting mismatched when their id was changed.

For those interested in what this change means, here’s how it works. First, if you’re not familiar with polymorphism, it’s similar to inheritance, but differs in that polymorphic subclasses share a common “identity”. Here’s what that means with respect to the data model. In typical inheritance, the subclasses inherit the traits (attributes) of their superclass, but they can’t stand-in for that superclass (i.e. their identity or type is unique). In polymorphic inheritance, the subclass still inherits the traits of the superclass, but is now also considered to be the “same” type as the superclass. This means that when you query for records of a polymorphic super type, you’ll also receive records of all the polymorphic sub types.

This is especially useful functionality, because data is often stored in exactly this type of generic manner. It’s typical in SQL databases to have a large table where certain attributes apply to one specific subtype of the data, other attributes apply to another subtype and some attributes apply to all. With polymorphism, we can model this situation precisely.

So how do we use it in SproutCore? It’s simply a matter of adding the isPolymorphic property to a record class and extending it. Let’s look at an example from the SC.Record documentation that will hopefully clear up any remaining confusion on how polymorphism works.

// This is the "root" polymorphic class. All subclasses of MyApp.Person 
// will be able to stand-in as a MyApp.Person.
 MyApp.Person = SC.Record.extend({
   isPolymorphic: true
 });
 
// As a polymorphic subclass, MyApp.Female is "equal" to a MyApp.Person.
 MyApp.Female = MyApp.Person.extend({
   isFemale: true
 });
 
// As a polymorphic subclass, MyApp.Male is "equal" to a MyApp.Person 
// also. Not it is not "equal" to a MyApp.Female.
 MyApp.Male = MyApp.Person.extend({
   isMale: true
 });
 
// Load two unique records into the store.
 MyApp.store.createRecord(MyApp.Female, { guid: '1' });
 MyApp.store.createRecord(MyApp.Male, { guid: '2' });
 
// Now we can see that these records are in fact "equal" to each other. 
// Which means that if we search for "people", we get "males" & 
// "females".
 var female = MyApp.store.find(MyApp.Person, '1'); // Returns record.
 var male = MyApp.store.find(MyApp.Person, '2'); // Returns record.
 
// These records are MyApp.Person as well as their unique subclass.
 SC.kindOf(female, MyApp.Female); // true
 SC.kindOf(male, MyApp.Male); // true

Enjoy!

SproutCore Book Available

written by Tyler Keating

Although it has been out for a couple weeks already, I had never officially announced the completion of the SproutCore Web Application Development book in this blog. So for anyone that has been waiting for a book on SproutCore, you should know that it has finally been completed and you can purchase a copy here.

This book covers almost every aspect of SproutCore with detailed explorations of the runtime environment, the MVC layers that SproutCore brings, using statecharts, interacting with multiple remote data stores and many many other topics all the way through to unit testing and deploying real SproutCore applications. So if you’re looking to take the next big leap in web software development and have ever been curious about SproutCore, now is your chance to learn everything you need to know in one easy read.

Thank you!

 

Dispatches From the Edge: Automatic Transitions and SC.View Optimizations

written by Tyler Keating

Version 1.10 is shaping up to be a fundamental advancement of SproutCore as the best framework for creating powerful user experiences on the web.  We’ve already been doing the best of breed practices for creating dynamic web applications for some time.  For example, running in the client, maintaining the application “truth” in code, minimizing touching the DOM and many other practices that keep SproutCore apps as fast as possible.  These features allow you to create extremely complex interfaces that update instantly as the user interacts with them.  However, while instant updates were a major advancement, they can give the interface a jarring feel and therefore the next level of application design is to go beyond instant updates and add “life” or “play” to your user interface with subtle transitions.

As such, SproutCore 1.10 will include a new automatic transition architecture that is so easy to use, developers can actually play around with complex transitions while first implementing a view rather than needing to commit more time to it later.  To do so, you simply specify a transition plugin to use during one of the four state changes: appending, becoming visible, becoming hidden and removing.  To make it even easier, SproutCore includes a few built-in transition plugins: SC.View.FADE, SC.View.MOVE, SC.View.BOUNCE, SC.View.SPRING and SC.View.SCALE and it’s very easy to write your own transition plugins to do any type of advanced animation based on the SC.Transition protocol.

Continue reading

SproutCore 1.9.2 Released

written by Tyler Keating

We are pleased to announce the immediate release of SproutCore 1.9.2.  This release contains important fixes to the 1.9 code-base and is fully backwards compatible.  We recommend that all users of SproutCore upgrade to this latest version in order to have the best development experience.  To upgrade to the latest version, simply run:

gem update sproutcore

This is a patch release and contains the following bug fixes:

Build Tools

  • We’ve softened the build tools dependency requirements from being ultra-pessimistic (i.e. within the minor version) to being just pessimistic (i.e. within the major version).  This helps to prevent Bundler conflicts.
  • Fixes the snake case generator for ‘sproutcore gen‘, so that names like ‘SCProject’ get properly transformed to ‘sc_project‘ and not ‘s_c_project‘.
  • Fixes the ‘$repeat: repeat‘ property used with the @slice SCSS directive when generating the @2x version.  It was incorrectly appending @2x to the end of the whole path (ex. /resources/images/image-sliced-from.png@2x) instead of inserting it before the extension (ex. /resources/images/image-sliced-from@2x.png).
  • Fixes incorrectly named “responder” generator to “state” generator for generating SC.State subclasses.  You can now generate an SC.State file using ‘sproutcore gen state‘ or ‘sc-gen state‘.
  • Added support for un-prefixed background-size CSS attribute when spriting.  This allows spriting to work properly in retina Firefox.
  • Fixes inconsistencies and improper syntax in several templates created with ‘sproutcore gen‘.  Generated files are now cleaner and provide more descriptive help comments.
  • Fixes missing stylesheet warnings on a clean app generated with ‘sproutcore gen app‘ or ‘sproutcore gen statechart_app‘ by adding a default stylesheet to the app. Also adds a default stylesheet to a design, when using ‘sproutcore gen design‘ (i.e. creating an SC.Page resource).

Framework

  • Fixes regression in IE7 and IE8 which caused XHR requests to fail to notify.
  • Fixes improper binary search used by SC.ManyArray.prototype.addInverseRecord that resulted in an infinite loop when using addInverseRecord with an orderBy function.
  • Fixes bug that allowed the context menu to appear regardless of overriding contextMenu in a view or setting SC.CONTEXT_MENU_ENABLED (globally) or isContextMenuEnabled (on a view) to false.  This makes the context menu event handling behave the same as the key, mouse, etc. event handling.
  • Fixes actions: insertNewLine, deleteForward, deleteBackward, moveLeft, moveRight, selectAll, moveUp and moveDown to be always handled by the SC.TextFieldView element when it has focus.
  • Fixes the hint value for SC.LabelView so that it will appear when the label has no value and isEditable is true.
  • No longer modifies the underlying items given to an SC.SegmentedView directly so that we don’t dirty the original objects.
  • Fixes debug files being included in builds. These files (one of which is a 2.5MB test image) would get included into every build, because they were at the wrong path.  These files should not ever be loaded in an app, but if you created an app manifest based on the contents of the built static directory, you could invariably cause the client to download over 2.5MB of files that are never used.
  • Fixes determination of touch support in Chrome on Win 8.
  • Adds missing un-prefixed border-radius rules to the default theme for browsers that have dropped the prefix.

As always, every bug fix includes an accompanying unit test to ensure that the bug does not re-appear in the future.

Dispatches From the Edge: Super Fast Collections

written by Tyler Keating

One of the most advanced changes coming in 1.10 is the formalization of a major enhancement to SproutCore’s collection views.  Some of you may have heard of, used or tried to use the SC.CollectionFastPath mixin which gives SproutCore’s collection views, namely SC.ListView and SC.GridView, a massive performance boost.  The performance boost comes from pooling the item view objects, pooling item view layers (i.e. elements) and re-positioning layers using layout styles without modifying the DOM tree.  By re-using objects and elements, we can increase the speed that our collections can update, making gigantic lists perform like butter, even on mobile.

However, using SC.CollectionFastPath was unwieldy and difficult to get working correctly.  Turning it on was not enough, you also had to provide a couple properties on your item view class that were totally undocumented.   Due to the fact that SC.CollectionView is already optimized to create item view objects and layers only for the visible portion of the collection, it could be hard to even be sure that the fast path code was active or not.  This is all changing in 1.10.

We believe that every SproutCore view should be as fast as possible out-of-the-box on every platform and so we’re making these improvements a part of SC.CollectionView directly.  This means that by default, SC.ListView and SC.GridView will be fully optimized without any further configuration.  That said, when creating custom item views, you should properly support render and update.  Since view performance is so important, you should already know how to do this and if you need a good example, check out the custom item views in the new demo in the SproutCore Showcase.  This demo was created to debug this new technology as well as to demonstrate working with gigantic lists.

For now, the feature is still being tested and fine-tuned and any additional real-world feedback is appreciated.  So please check it out on the SproutCore master branch and bring any issues forward so that they can be addressed before release.

Thanks!

 

For discussion, please use sproutcore@googlegroups.com or #sproutcore on IRC.

Note:  Whereas, before you needed to set properties to turn this on, you have to set properties to turn it off right now.  If for whatever reason, you don’t want to pool elements, you can set isLayerReusable to false on your custom item view and if you don’t want to pool views, you can set isReusable to false as well.

Dispatches From the Edge: Invoking “Next”

written by Tyler Keating

As the 1.10 release nears completion, I thought I’d better start writing about some of the many improvements now, lest the final release blog post would take me two days to write.  A lot of the changes, including today’s topic, were the result of working on big feature additions and discovering that more support was needed closer to the core.  Which brings me to the topic of this post:  SC.RunLoop.prototype.invokeNext. Continue reading

Wesley Workman & Tim Evans are now SproutCore Reviewers

written by Tyler Keating

Please join us in congratulating Tim and Wesley on achieving SproutCore Reviewer status.  They are two of the most active contributors and have shown that they share our ideal of making SproutCore the most feature rich and highest quality application development framework.

More importantly, please join us in thanking Tim and Wesley and all the Committers and Reviewers for the work they’ve done to get us here.  We ask a lot of our burgeoning team and we are fortunate to have such people.