So, one of the things that becomes interesting as one starts to do high frequency Cairo calls from VisualWorks, is how much of a speed hit we pay every time we cross the boundary between Smalltalk and a C function in an external library. There's lots of anecdotal evidence that the VisualWorks call engine is slower than that provided by some of the other historical Smalltalks. But no one that I've talked to seems to have numbers on what takes so long. Is it sync'ing the stacks? Call overhead? Marshalling?

So I thought I'd sit down and write a simple test that takes a cursory look at marshalling speeds. The idea is to bind a function that takes no arguments and has a void return. And then time a run of some number of iterations (10,000,000 in this case). Then we can create variants that add marshalling overhead and compare. Hopefully the VM-Guys-We-Keep-Chained-To-The-Build-Machines-In-The-Closet can make some small use of the data.

So, I could have just tabulated the results and passed those on. But pictures tell such a better story. And I'm really excited to play with some of these tools that Cairo gives to me. So I did just that:

Basically, each test was run 10 times (10,000,000) iterations each. There's a baseline as mentioned. And then 4 functions which take int's as args, one with one arge, the next with two, then three, then four. After that is the same pattern repeated, but for doubles. And then those same four repeated, but ints are passed in to the double functions to test the transcendental marshalling. The final three have no args, but test the marshalling the speed of simple return values, the first being an int, the second being a float, and finally a double. I kept the integers out of LargeInteger land. Though that could be interesting. One reason for wanting to plot it this way, is that I could see that there was quite a spread in the values being returned. External calls are much more "jittery" (i.e. less deterministic) than say, method calls. I've run these kinds of tests before to see the affect of number of arguments on method dispatch, and the numbers are very repeatable. The overhead of marshalling appears to be roughly linear based on number of arguments.

OK, so that aside, I just think the chart's cool. It may not be the best way to present the data. I had lots of different ideas. But I have Tools work to do too. One thing that's neat is that you can draw all of those grid lines at once as it were. You set up the path, and then just tell it to stroke. Non-contiguous strokes are no problem in Cairo. I purposely rotated the text 75 degrees to show arbitrary anti-aliased text rotation (because everyone knows that if you get despate for 90 degree text in VW, you can draw a Mask with the text and rotateQuadrants: 1). And then there's the gradients. Basically for each data point, I draw a little alpha linear gradient bar. It peaks at 40% alpha in the center. You can see a couple of outliers. But by drawing it for each of the 10 values, you can see where they cluster, because the alpha values add up. There is simply no way to do this kind of thing effectively using the current VW graphics model.

Update: Added the cheesy lens flare in there. Definitely not gonna do that with VW GraphicsContext.