Here is something interesting. I compared the two compute engines of the old TFlag and the new TTapestry and found the following:

tf := TFlag new.

tt :=TTapestry new.

( the results are in milliseconds)

[1000 timesRepeat:[ tf step ]]timeToRun 8608

[1000 timesRepeat: [tt testCompute]]timeToRun 9528

[10000 timesRepeat:[ tf step ]]timeToRun 80553

[10000 timesRepeat:[ tt testCompute]]timeToRun 92868

I presume that what this means is the much simpler code of TTapestry, which yields nearly identical qualitative results does not take that much longer than the array juggling that TFlag has to do.

A fifteen percent increase in compute time is a small cost to pay for the code being so much more readable. Also, though I can't imagine where I could speed up the TFlag computation, as it is so complex, I am sure I could easily find a few additional cycles in the TTapestry. But then, perhaps I am missing something?

The new classes are posted as Croquet updates. See TTapestry for how to use.

## Saturday, October 16, 2004

Subscribe to:
Post Comments (Atom)

## 2 comments:

Well, one obvious thing to optimize would be to *not* calculate the vector's length twice in your "improved" B3DVector3>>normalized method ;-)

Actually, IMHO you should have used the existing #safelyNormalize(d?) method. Which of course could also be improved a teensy bit by using lengthSquared and doing the square root only if necessary.

- Bert -

Yes, you are right. I should have thought that we would have such a method somewhere. The updated numbers look like:

[1000 timesRepeat:[tf step]]timeToRun 8473

[1000 timesRepeat:[tt testCompute]]timeToRun 9009

This is after removing some additional unused calculations.

Post a Comment