I'll check the difference. But it seems to me that for this purpose ("which of A and B is more expensive") it doesn't matter since we're interested in the relative speed of code.

I think getting as close as possible to the actual cost of a single UGen would be useful. We may have several ways of constructing a certain sound out of a few UGens, in that case the relative cost of single UGens would be quite relevant. I recognise that we may not be able to find the exact cost in all cases as it may depend on the context, especially if/when we would start optimising ChucK but it could still be interesting to get as close as possible.

Even the question of whether or not such a difference really exists in a appreciable form would be interesting; such info would help us make more informed choices about the the structure of our programs.

Agreed, and I have lot's of other ideas + plan on testing things as they occur in my work.

Great! I'm looking forward to reading about this.

You're absolutely right. I actually started something automatic, but got stuck, and thought a "by-hand" start was better than nothing. I'll for sure see if I can make a 100% automatic test.

Oh, yes, clearly, this is already quite interesting.

Eric had a interesting note about different kernels; I wonder whether that would make a difference beyond the relative cost of UGens compared to eachother (as percentages) and the overhead cost any given OS has for running a program at all. I could imagine different CPU's making a difference, provided we have a good compiler and compile each on it's own system. We could create a standard for testing this; for example saying the cost of a single SinOsc is "1", always using the same buffer size and so on.