Posts Tagged Google

To Optimize or Not To Optimize

corey602Developing an on-demand platform that must deliver speed, scalability and stability requires a lot of thinking about performance. While working on Bungee Connect, I’ve done enough code optimizations, tweaks, hacks, anything really to squeeze more performance to know that I need to pay attention to the details up front. Not to poke the “don’t optimize until it’s done” beehive, but I’ve learned enough to know that there are some things you can learn from experience and you don’t have to wait for the performance guys to laugh at your code.

Have you ever debugged a crash where a null pointer was being dereferenced and when you tracked down the individual responsible their defense was that checking for null would slow down the system?  Have you ever found someone that wrote their own atoi function because they swore that the standard c runtime’s implementation was bad?

If you read my previous post you’ll know that I’ve been playing with the V8 JavaScript engine by Google.  I’ve enjoyed learning a new system and gleaning tricks from other programmers that you don’t get from reading a book or taking a class. But something has been gnawing on my mind for the last little while and that is how fast or slow is the bridge between the v8 engine and a c++ application that embeds it.  I wondered whether or not a developer should be worried about the performance of this bridge or if they should forget about performance for now and just start turning the crank on features. So I wrote a little performance test to see how long different areas of the V8 integration into an application take. By the way, the Google engineers that wrote this system are very solid in terms of coding standards, efficiency and readability.

These benchmarks aren’t the most scientific in nature but they do give me something to start kicking around.  Here’s the JavaScript test that I wrote and embedded into my test:

var count = 0;

function timed_dispatch() {
count += 1;

start = new Date();

// Test 1
for (i = 0; i < 1000000; i++) {
count += 1;

// get the time and print the results
end = new Date();
print(end - start);

// reset the counter and the start timer
count = 0;
start = new Date();

// Test 2
for (i = 0; i < 1000000; i++) {

end = new Date();
print(end - start);

// Setup for Test 3
timed_obj = new TimedCPPDispatch();
start = new Date();

// Test 3
for (i = 0; i < 1000000; i++) {

end = new Date();
print(end - start);");

The first for loop measures how long it takes V8 to do some simple arithmetic on a variable.  I started with 10,000 iterations but the numbers were too small so I bumped it up to 1,000,000.  The output of the first print statement was 16ms.  Pretty quick.

The second for loop looks at how long it takes to do a method dispatch that increments the same number.  Adding the overhead of the function call took the time up 4ms for a grande total of 20ms.

The last for loop uses a C++ class that I created that has a function called empty.  This function literally does nothing except for return.  What I’m looking for is how long the act of dispatching a method from the javascript to the c++ application takes.  It took a total of 1500ms or 1.5 seconds to call 1,000,000 times.

Obviously, if you can avoid crossing the boundaries between your application and the V8 engine you will be saving some overhead.  Two orders of magnitude difference is nothing to sneeze at.  However, 1.5 us (microseconds) per function call is not bad for an embedded vm.  And, I don’t expect anybody to be doing a million of those. On top of that, once you cross the boundary you’re still running in c++ code, which isn’t too shabby with performance either.  If you have some complicated c++ algorithm that you are calling then a 1.5 us boundary becomes noise and is not an issue.  So, the old adage of not optimizing too soon would appear to still hold a lot of water in this argument and I should hold off on looking to outsmart myself before that’s really necessary.  I should probably be looking to add features to my application rather than trying to figure out a priori where my code might be slowing down.

If you’re interested in checking out V8’s performance numbers for running straight JavaScript head on over to or download the V8 engine and run them on your machine.

Leave a Comment

BCDN Update, October 2008

This month’s newsletter was sent to all BCDN developers on Wednesday, October 8, 2008.

Since sending the email, there has been one modification to the original newsletter’s information. The new release of Bungee Connect will happen on Monday, October 13, not today. (I forgot about a cardinal rule of new releases, as set by BCDN members: never do a system update on a Friday. My bad!)

Hey, everyone:

It’s been a while since the last Bungee Connect Developer Network update, and we have been cooking up some great stuff for you. Let’s get to it. Read the rest of this entry »

Leave a Comment

Connecting C++ To Javascript Via Google’s V8

I’ve been playing around with Google’s V8 JavaScript engine. One of the really cool things about V8 is that it was built to be embedded into a C++ application. Here at Bungee Labs I’ve been writing the infrastructure for our bungee connect platform for some time now. One thing that I’m always interested in is speed and V8 is very fast. I ran the benchmarks that Google posted in my browser (Firefox 3.03), and then I ran them using the new V8 engine. The new engine is faster by an order of magnitude. Read the rest of this entry »

Comments (2)

It’s Official: Bungee Connect Now Supports Google Chrome

Today, Bungee Labs announced our official move to support Google’s new browser, Google Chrome. See “Bungee Connect: First Platform-as-a-Service to Offer ‘Write Once, Run Anywhere’ Support for All Major Browsers, Including Google Chrome” for details.

Shortly after Google released the Chrome beta, our test team went to work to identify exactly what worked and what didn’t. They found that Google Chrome loaded and ran Bungee-powered applications with only a few issues, which we detail below. Read the rest of this entry »

Comments (2)

JavaScript Biggest Threat to Silverlight?

In light of the recent announcement about Google Chrome, I found a couple articles particularly interesting:

If indeed Microsoft sees JavaScript as Silverlight’s biggest competitive threat, and Mozilla and Google are apparently squaring off for an arms race around JavaScript performance, this bodes extremely well for the future of web applications built on standards-based JavaScript.

Leave a Comment

WideLens in Google Chrome

Our product manager Dave Brooksby continues to test Google Chrome. Today he sent me a screenshot of our demo application for calendar management, WideLens.

Is it just me, or does Google Chrome look like it was designed for Bungee-powered applications?

(click image to embiggen) Read the rest of this entry »

Leave a Comment

Bungee Connect in Google Chrome

The first question we at Bungee Labs thought when we read the news about Google’s nifty new browser, Google Chrome, was: I wonder how it will do running Bungee Connect?

Google chose to use WebKit, the same rendering engine as Safari, which we support for Bungee Connect. So far, so good:

(click either image to embiggen)

But they also state that they chose to create a wholly new Javascript engine. Hrmmm…

In our early tests, we have found that there are at least a few controls that exhibit issues. Mostly, issues seem to be little interaction annoyances, such as having to click on a Tree control a second time before you can interact with it.

So, we make no formal announcement of support for Chrome yet (Come on! Chrome was just introduced and is still in beta!), but the Bungee Boys are smiling.

Comments (3)

@task, with Nate Bowler

The Bungee LineOverview
Nate Bowler, CTO of @task, becomes our first in-studio guest on the Bungee Line. @task provides project management, Gantt chart, workflow, and time tracking software through both traditional host-your-own and Software-as-a-Service models. As with so many companies in the providing web-based software, they provide an API.
36:25, 16.7 MB

Related Links
Here are links to some of the resources mentioned in this episode. Read the rest of this entry »

Comments (1)

Delegated Web Authentication in Bungee Connect

One of the newest features in Bungee Connect is the ability to leverage existing authentication services instead of developing your own authentication. This is advantageous both in the terms of development time and security. By using DWA, developers make their applications easier to use, since their target audience won’t have to create yet another set of credentials for a web application. Currently, Delegated Web Authentication is available for Facebook, Google, and Windows Live. Read the rest of this entry »

Comments (4)

Startup Series video from Web 2.0 Expo

Picture 3.png

While at Web 2.0 Expo, Jesse Stay interviewed me and Corey Olsen about Bungee Connect. He just updated his blog with some video of the demo we gave him.

Tonight we will be hosting the Social Media Developers Garage. At the event tonight, Ted Haeger and I will be providing a Hello World introduction to using Bungee Connect with a few services like Facebook, Twitter and possibly even Google Contacts.


Leave a Comment

Older Posts »