whoa! why do you have sendallsprites inside a repeat loop? doesn't that defeat the porpoise?
--bhakti Perry wrote: > > > I like the research! Can you do a test where there are lots and lots > > of sprites, but that only a few have the handler? Compare that > > against there only being those few sprites. > > Ah. I'm glad you asked. I did do some more tests, actually. > > I modified the original movie script: > > -------------------- > global gCounter > > -- consecutive sprites > on test(sprLow, sprHigh) > testMax = 10000 > > gCounter=0 > t=the milliseconds > repeat with j=1 to testMax > sendAllsprites(#doit) > end repeat > > put the milliseconds-t > put gCounter > > gCounter=0 > t=the milliseconds > repeat with j=1 to testMax > repeat with i = sprLow to sprHigh > sendsprite(i, #doit) > end repeat > end repeat > > put the milliseconds-t > put gCounter > END test > > -- unevenly distributed sprites > on otherTest aList > testMax = 10000 > > gCounter=0 > t=the milliseconds > repeat with j=1 to testMax > sendAllsprites(#doit) > end repeat > > put the milliseconds-t > put gCounter > > gCounter=0 > t=the milliseconds > repeat with j=1 to testMax > repeat with i in aList > sendsprite(i, #doit) > end repeat > end repeat > > put the milliseconds-t > put gCounter > END otherTest > > I set up 8 test conditions, but it's all evident from my msg window output, > so here it is: > > -- Test 1 (10 sprites only, all behaviored, consecutive) > > test(1,10) > -- 385 > -- 100000 > -- 878 > -- 100000 > > test(496,505) > -- 384 > -- 100000 > -- 882 > -- 100000 > > test(991,1000) > -- 385 > -- 100000 > -- 874 > -- 100000 > > -- 10 sprites only, all behaviored, unevenly distributed > otherTest([42, 145, 255, 531, 532, 547, 592, 911, 937, 964]) > -- 3345 > -- 100000 > -- 922 > -- 100000 > > -- Test 2 (1000 sprites, 10 behaviored, consecutive) > > test(1,10) > -- 4930 > -- 100000 > -- 881 > -- 100000 > > test(496, 505) > -- 4947 > -- 100000 > -- 878 > -- 100000 > > test(991,1000) > -- 4992 > -- 100000 > -- 872 > -- 100000 > > -- 1000 sprites, 10 behaviored, unevenly distributed > otherTest([42, 145, 255, 531, 532, 547, 592, 911, 937, 964]) > -- 4972 > -- 100000 > -- 921 > -- 100000 > > My my. Warren said that sendAll is orders of magnitude faster and I agreed > with him, now I'm seeing that it's half an order of magnitude the other > friggin' way. > > But wait. There's more. > > I added a 2nd behavior to the sprites and ran the tests again. Here's the > new behavior and accompanying movie script: > > ---------------------- > -- Behavior script > -- attached to every sprite that already had a behavior in the 1st series of > tests > > property pIntCounter > > on beginSprite me > pIntCounter = 0 > end beginSprite > > on incCounter me > pIntCounter = pIntCounter + 1 > end incCounter > > on queryCounter me > put pIntCounter > end queryCounter > > ---------------------- > > -- Movie script > > on newTest(sprLow, sprHigh) > testMax = 10000 > > t=the milliseconds > repeat with j=1 to testMax > sendAllsprites(#doit) > sendAllSprites(#incCounter) > end repeat > > sendAllSprites(#queryCounter) > put the milliseconds-t > > t=the milliseconds > repeat with j=1 to testMax > repeat with i = sprLow to sprHigh > sendsprite(i, #doit) > sendSprite(i, #incCounter) > end repeat > end repeat > > repeat with k = sprLow to sprHigh > sendSprite(k, #queryCounter) > end repeat > > put the milliseconds-t > END test > > on newOtherTest aList > testMax = 10000 > > t=the milliseconds > repeat with j=1 to testMax > sendAllsprites(#doit) > sendAllSprites(#incCounter) > end repeat > > sendAllSprites(#queryCounter) > put the milliseconds-t > > t=the milliseconds > repeat with j=1 to testMax > repeat with i in aList > sendsprite(i, #doit) > sendsprite(i, #incCounter) > end repeat > end repeat > > repeat with k in aList > sendSprite(i, #queryCounter) > end repeat > > put the milliseconds-t > END otherTest > > ------------------ > > The results: > (With 10 sprites being queried and all returning identical pIntCounter > values, I've snipped out 9 redundant outputs, to save space). Also remember > that I've reversed the output, ie: > -- pIntCounter > -- time taken > -- pIntCounter > -- time taken > > Here we go: > > -- Test 1 (10 sprites only, all behaviored, consecutive) > > newTest(1,10) > -- 10000 > -- 814 > -- 20000 > -- 1722 > > newTest(496,505) > -- 10000 > -- 817 > -- 20000 > -- 1728 > > newTest(991,1000) > -- 10000 > -- 845 > -- 20000 > -- 1778 > > -- 10 sprites only, all behaviored, unevenly distributed > newOtherTest([42, 145, 255, 531, 532, 547, 592, 911, 937, 964]) > -- 10000 > -- 6772 > -- 20000 > -- 1802 > > -- Test 2 (1000 sprites, 10 behaviored, consecutive) > > newTest(1,10) > -- 10000 > -- 9895 > -- 20000 > -- 1723 > > newTest(496, 505) > -- 10000 > -- 9940 > -- 20000 > -- 1719 > > newTest(991,1000) > -- 10000 > -- 10010 > -- 20000 > -- 1790 > > -- 1000 sprites, 10 behaviored, unevenly distributed > newOtherTest([42, 145, 255, 531, 532, 547, 592, 911, 937, 964]) > -- 10000 > -- 10017 > -- 20000 > -- 1787 > > -------------- > > So, what have we? > > It's clear that the deeper in the score the sprites ar e, the longer it > takes for sendAllSprites to message those sprites, suggesting that Director > is actually looking at each occupied channel iteratively -- rather > inelegant, really. > > This suggests that there is in fact no container tucked away somewhere in > RAM that keeps track of which sprite owns which handler. Does anyone in the > know care to enlighten me on this? > > I see that if I want to speed up the sendAllSprites search, I'll have to run > some experiments on setting up my own handlerManagerList at sprite > initialisation. But then I'd have to iterate through that list anyway, so > what's the friggin' point? > > What else can we conclude? > > Let's see. With lots of sprites in the score sendAll is damn slow compared > to "repeat with i = a to b", even "repeat with i in aList". Also, even if > there are few sprites in the score, if the sprites are not consective -- > quite likely in many situations -- sendAll is also very slow. > > Oh well. SendAllSprites is very handy, quite flexible, but can be rather > slow. Sort of handy to know, but also rather disappointing. > > Pez > > [To remove yourself from this list, or to change to digest mode, go to >http://www.penworks.com/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!] [To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/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!]
