At 19:23 -0400 22/06/01, Bill Numerick wrote:
>OK just did that :) Except its not a totally fair comparison since
>i'm at home now on my 900 mhz Athlon and at work i have a 400 mhz G4
>so i'll test it Monday but here's what i got.
>
>Here's the script since it wasn't in the message from before
> startTime = the milliseconds
> call #setWindow, gTestList, gContentSprites, gMaxVisible
> put "call test took" && (the milliseconds - startTime)
>
>5 sprites: 82
>10 sprites: 96
>15 sprites: 90
>20 sprites: 95
>25 sprites: 99
>30 sprites: 103
>35 sprites: 110
>40 sprites: 117
>50 sprites: 134
>75 sprites: 175
>100 sprites: 239
>
>MUCH MUCH faster ;). I'll post the results from my machine at work
>which I'm assuming will be a little slower on Monday. Thanks for
>feedback on this.
I don't understand these test results. How can it take so long to
call 100 sprites?
Is the handler #setWindow actually doing something? because then
you're not testing the speed of the messaging architecture, but
rather the execution speed of whatever code you put into #setWindow.
Important distinction approaching:
Sprite/SpriteObject/SpriteRef versus Object/ScriptInstance/behavior
Anyway, as usual I will point out, that if you want to address a
behavior, ie. an object in the scriptInstanceList of a sprite, then
it is faster to send messages directly to the object rather than
having the method routed through the multiple-inheritance-mechanism
of the sprite.
Therefore rather than "calling" a premade list of spriteobjects, it
would be more efficient to "call" a premade list of scriptInstances
aka. "objects".
Such a list can easily be made by a sendAllSprites once.
pList = []
sendAllSprites #mCollectThoseObjects, pList
And in the behavior:
on mCollectThoseObjects me, aList
aList.add(me)
end
Or, if you want all behaviors on the sprite:
on mCollectThoseObjects me, aList
repeat with tBhv in sprite(me.spriteNum).scriptInstanceList
aList.add(tBhv)
end repeat
end
So rather than calling a list of sprites, that would then each call
their "sublist" of objects, you're essentially unwrapping all the
sublists into one big list, which you can then call directly.
Here, a test to show the performance difference between addressing
the sprite and the behavior:
on beginSprite me
pSprite = sprite me.spriteNum
----
tStop = the milliSeconds + 1000
tBaseIterations = 0
repeat while the milliSeconds < tStop
tBaseIterations = tBaseIterations + 1
end repeat
put #base_iterations, tBaseIterations
----
tStop = the milliSeconds + 1000
tBehaviorIterations = 0
repeat while the milliSeconds < tStop
tBehaviorIterations = tBehaviorIterations + 1
call #mTest, me
end repeat
put #behavior_iterations, tBehaviorIterations
----
tStop = the milliSeconds + 1000
tSpriteIterations = 0
repeat while the milliSeconds < tStop
tSpriteIterations = tSpriteIterations + 1
call #mTest, pSprite
end repeat
put #sprite_iterations, tSpriteIterations
----
tBaseTime = 1.0 / tBaseIterations
tBehaviorTime = (1.0 / tBehaviorIterations) - tBaseTime
tSpriteTime = (1.0 / tSpriteIterations) - tBaseTime
tFactor = tSpriteTime / tBehaviorTime
put #factor, tFactor
----
halt
end
on mTest me
end
-- #base_iterations 55304
-- #behavior_iterations 39338
-- #sprite_iterations 30862
-- #factor 1.9513
Addressing the behavior directly is almost twice as fast.
Not strange, considering that you are effectively cutting the
messagepath in half.
Then when your tests have established the fastest procedures, you'll
notice that the difference quickly becomes negligible, as soon as you
actually start doing something in the behavior, such as moving a
sprite, causing stagePixels to change.
Most of this discussion has been covered before.
Jakob
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED])
Lingo-L is for learning and helping with programming Lingo. Thanks!]
