Bungee Connect Developer Network

Developing 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++) {
timed_dispatch();
}

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++) {
timed_obj.empty();
}

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 http://code.google.com/apis/v8/run.html or download the V8 engine and run them on your machine.