Optimizing App Performance with SC.Benchmark

written by Peter Bergstrom

3 Comments

SproutCore is a powerful JavaScript framework that allows developers to take full advantage of the code design paradigms used for native applications developed in languages like Cocoa. However, the tools that are available for web development are different and, in most ways, more basic than what is available when writing native applications.

One of the major challenges developing SproutCore applications is measuring the performance of your application. The major web browsers all have built-in profilers that allow developers to examine the overall performance of their application. These profilers allow you to easily track the execution of operations from start to finish, but they do not provide an easy way to optimize specific portions of code.

One of the less known features of SproutCore is SC.Benchmark, a built-in benchmarking tool that developers can, and should, use to optimize their application. There are several ways to report the data captured using SC.Benchmark, including aggregate reports and graphs.

It is very simple to use and can be used anywhere in a SproutCore application. Each benchmark needs a key value. This key value does not need to be unique if you want to get averages for benchmarks over many runs of a code segment. To start the benchmark, you add SC.Benchmark.start("my benchmark key"); to your function. To stop it, you add SC.Benchmark.end("my benchmark key");

Benchmarking Functions and Loops

In the example below, you can see it used inside of a function to capture the execution time for creating a number of SproutCore objects.

createObjects: function(klass, count) {
	SC.Benchmark.start("createObjects");
 
	var objects = [];
	for(var i=0; i<count ; i++) {
		objects.push(klass.create());
	}
 
	SC.Benchmark.end("createObjects");
}

Continue reading

Structuring Your SproutCore Application: Part 2

written by Colin Campbell

1 Comment

In Part 1, we started developing a Contact application for managing groups and people. Continuing with Part 2, we’re going to be implementing the application’s functionality in a way that’s going to scale with its complexity.

Loading The Application’s Data

Now that we have the base of our application, we need to start by loading some data into the application. Before we proceed, let’s make sure we’re on the same page. Check out step 4:

	git checkout step4

We’re going to do this using `SC.FixturesDataSource`. It allows you to use fixture data local to your application, but also simulates remote responses. That means when you implement a connection to a remote server, your application works as expected. Let’s create the FixturesDataSource in `apps/contact/data_sources/fixtures.js`:

1
2
3
4
	Contact.FixturesDataSource = SC.FixturesDataSource.extend({
	  simulateRemoteResponse: YES,
	  latency: 250
	});

We’ve defined a new FixturesDataSource class, turned on the simulation of remote responses, and set the latency to 250ms. This is a typical amount of latency between a client and a server but you can tweak this number to suit your needs.
Continue reading

Video from the July SF Meetup – SproutCore UI and Community Q&A

written by Madeleine Douglas

Comments Off

Thanks to everyone who came out for the SF SproutCore Meetup this past Tuesday! For those of you who couldn’t make it, Majd Taby gave a talk about what’s coming in SproutCore UI; afterward, we had a town hall meeting about SproutCore 2.0 and a variety of other questions from the community. We even had Yehuda Katz give an impromptu presentation!

We’ve included video from the talk and from the Q&A below. Thanks again to our friends at Yelp for providing us with pizza, beer, and a recording with audio so clear it sparkles!

Check out Majd’s talk on SproutCore UI:

You can follow along with his slides, available here.

Here’s the Q&A that followed:

One of our first community questions, about choosing which version of SproutCore to use:

There are more questions and answers from the evening’s town hall online on the SproutCore Vimeo account. Take a look—they might have answered your questions!


Other meetups this month:

  • Kuala Lumpur, July 23, featuring a remote talk by Greg Moeck!
  • Vancouver, July 26, featuring talks by Tom Dale and community member Luis Sala!

The Run Loop: Part 2

written by Tyler Keating

4 Comments

Previously, we delved into the operation of SproutCore’s RunLoop, a powerful mechanism that we rarely work with directly. While understanding the function of the Run Loop is akin to understanding the function of your vehicle’s transmission– you don’t need to know how it works in order to go really fast – they both definitely help you go really fast.

So, as promised in the last post, let’s look a bit further at what we get out of having a Run Loop in SproutCore.

You DOM the Truth? You DOM the Truth!? The DOM can’t handle the Truth!

In a lot of web applications, the first wall that developers hit as the application grows in complexity is that they can no longer keep data synchronized throughout the application. This is typically because they’re using selectors to pull and push data to and from the DOM and it quickly gets out of hand, in particular when you add the complexity of synchronization with a backend and multiple event entry points.

SproutCore’s answer to this has always been that the application has a single “truth” which is maintained in the Model layer. To represent a change in the View layer, you make a change to the underlying Model data and let bindings take care of the rest.
Continue reading