Even though our flagship map is Flash, we write a lot of JavaScript at TransLoc and we wanted to know just how much of a performance hit is incurred when using various kinds of getter and setter functions on objects (as compared to directly accessing the member variables themselves.)  We designed, implemented, and ran a number of tests using the great tools at jsPerf.com and will discuss the results in the rest of the article.

There are at least 5 ways to access and modify a member variable’s value out of an object:

1. directly accessing it,
2. using an old-fashioned getFoo() or setFoo() method,
3. calling an attribute getter/setter built into the object prototype,
4. calling an attribute getter/setter created with __defineGetter__/__defineSetter__, or
5. calling an ECMAScript 5 property getter/setter.

Unfortunately ECMAScript 5 support is weak in most non WebKit browsers besides Firefox 4, so our data only reflects results from those browsers.  You can take a look at our test cases and run them yourself by going to the jsPerf pages here and here. Anyway, without further ado, to the charts!:

Results

* Chrome 9 and Firefox 4b13 were performed on a Linux Workstation, while the other browsers were tested on a Core 2 Duo Macbook Pro.

These results say several not-so-surprising things to us:

• The built-in JavaScript and ECMAScript getter/setter support provided across all browsers is not even in the same ballpark performance-wise as directly accessing member variables.
• The built-in getter/setter support also can’t compete with the old fashioned implementations of getFoo()/setFoo()

They also say one really strange and mystifying thing:

Firefox 4 would rather you write getters and setters the old fashioned way for every single object you create than reference objects’ member variables directly via dot-notation.

What the heck?

Well, we hypothesized this result was because Firefox might be caching the output of frequently-called functions when values are not changed.  To test this hypothesis, we created this performance test which calls both the setter and the getter: setting the new value of foo to the old value of foo plus a random number.  Here are the results:

It looks like we might have been right in our hypothesis.  Not only is Firefox 4 really fast, but it’s smart too.  Additionally, we think it’s safe to say that the getter/setter functionality built into JavaScript as a language isn’t ready for the prime time just yet – even if it does make your code prettier.

We already know we do a great job at showing where vehicles are in real time on a map, you can see for yourself at any one of our clients’ sites. (e.g. The University of Florida or NC State)

However, what would happen if we decided to turn the experience inside-out? Literally.

This is where the “Driver’s Seat” experiment comes in!  Last week we quickly whipped together a prototype of our Transit Visualization System in the first person using Google’s Street View API and the data feeds from our flagship Flash-based map.  The result is an immersive experience where you’re put at the driver’s seat of a vehicle at a randomly-selected client’s transit system. Watch as you see the view update in real time, following the vehicle along the road as it travels its route.

What we’ve learned from this experiment already:

As it turns out, Street View isn’t quite ready for realtime information with their current API.  We need to figure out a better way to show movement from one location to another; simply setting the position to a new latitude and longitude doesn’t give us the smooth transition effect that you’re used to seeing by clicking on the road arrows in a Street View display at maps.google.com.  Instead, the view just jumps to the new location and loads in the panorama tiles all over again.

Additionally, it has become apparent that although the Street View cars have been working very hard lately, the coverage can still be pretty spotty.  You might notice that the Driver’s Seat view will update for a while and then suddenly stop, or worse: upon loading Driver’s Seat you’ll be greeted with a big blank screen. This is because the location of the randomly-selected bus is too far from a stretch of road photographed by Google.  If either issue happens to you while using Driver’s Seat, just refresh the page to be given a new randomly-selected vehicle.

Take a ride in the Driver’s Seat!

Hello and welcome!

When we want to experiment with exciting new ways of displaying, manipulating, and storing the huge amounts of realtime data we receive on a daily basis from our clients, we come here: TransLōc Labs.  We’ve decided to start making some of our experiments visible to the public and created this blog to serve as the labs’ presence on the web. On this site you’ll find:

• early releases of our experiments to play with,
• in-depth technical blog posts on the topics we’re most passionate about,
• and discussion of news pertaining to the development team and our activities.

Stay tuned!