22 Replies Latest reply on Jul 31, 2008 9:58 PM by pete.h

    Optimizing Performance

    DaveGallant Level 1
      I am having a problem with my program as I am not getting the desired frame rate due to all the code that is getting executed per tick. So I have some questions about director and lingo as to which way actually executes faster.

      1. Multiple ExitFrame calls vs a single ExitFrame call.

      I have alot of sprites in my app. Almost all of them have an ExitFrame handler.
      Question: is it faster to have each sprite handle it's own ExitFrame routine and do code specific to that sprite or is it faster to have one generic ExitFrame to loop through and execute code for each sprite?

      2. Puppeted sprites vs Non-Puppeted sprites.

      I have a alot of sprites in my program. To make life ALOT easier, I simply allocated a good chunk of sprite channels to sole use of "dynamically created sprites". My program can have hunders of puppeted sprites from any given moment to the next.
      Question: Does director progress faster or slower depending on if a sprite is puppeted or not? Or is there any difference at all?

      3. Checking to see if a variable is set before setting it.

      I have only recently come into the Director/Lingo world of programming. I am originally a VB programmer for almost a decade. In visual basic, I have noticed that the code executes faster if you don't do unneeded variable assignments by checking to see if it was already set.

      Example: In visual basic, let's say you have an array of 1000 elements, some elements are already set, some are not.

      for i = 1 to 1000
      var(i) = i
      next

      The above code executes fast, but if you are doing that very very often, it can be a bottle neck.
      the below code, while doing the exact same thing, actually is faster.

      for i = 1 to 1000
      if var(i) <> i then var(i) = i
      next

      In VB, it's faster to do a check of a variable than it is to do the assignment when it's not needed. Now granted, this is a poor example, usually I am dealing with much more complex routines, but the basic principle of what I am trying to get across is the same.

      Question: in Director/lingo, would it speed up the execution of code to do a variable check before the assignment, or is the very act of adding the check going to slow the down the execution?



      Anyone have any ideas about these? Or anyone have any other tips about stupid little things to speed up execution of code?
        • 1. Re: Optimizing Performance
          Level 7
          > 1. Multiple ExitFrame calls vs a single ExitFrame
          > call.

          You should consider dropping the exitframe approach, in favor of an oop
          model.
          OOP is not faster, as a dual core processor is not faster than a single core
          one running at double the speed. In fact, the second should be faster, since
          there is no synchronization penalty. However, it is much smoother. Same with
          oop, you have a penalty, since you are using more objects, but the objects
          can be smart enough to adjust the number of instructions they execute as
          required.
          If you e.g. have objects whose coordinates can be calculated and stored
          inside the object, you don't have to update the stage each time an object
          moves. You can do that once, for all objects in set intervals. Long as the
          interval is large enough to handle all intermediate processing and
          updatestage cost, you'll have a very smooth movie.

          > 2. Puppeted sprites vs Non-Puppeted sprites.
          Puppeting does not affect performance -or at least it shouldn't. The number
          of sprites, and number of behaviors attached to each sprite does. However,
          even when there is a very large number of sprites active, the procedure
          should be a joke for any modern cpu. What does cost, is redrawing the
          sprites. So, if it's image sprites we are talking about, you should perhaps
          consider a single bitmap member you should use as a buffer, and imaging
          lingo for drawing each frame. The mouse click events can be evaluated by
          keeping a list of virtual sprite positions. Even if not familiar with the
          above, the time you'll invest in learning what is required, will be rewarded
          with a significant -up to times x- performance increase.

          > 3. Checking to see if a variable is set before setting it.
          You can create a simple lingo benchmarking script to get your answers. As a
          general principle, the less commands the faster. Though not really into VB
          (I find c++ and lingo to be a killer combination), I can assume why this is
          happening: when setting a variable, vb is executing some code to evaluate
          what the value was, and what -if anything- has to be released. Though
          nowhere documented, it seems that several years ago, someone in the director
          dev team was smart enough to take this matter into account when creating the
          object that is known as a lingo variable (64bit internally, btw). So,
          director doesn't suffer slow variable release - releasing what shouldn't be
          released that is.


          > Anyone have any ideas about these? Or anyone have any other tips about
          > stupid
          > little things to speed up execution of code?
          You know, a few years ago, lingo performance/speeding up director was a
          regular discussion issue in this list. This is not the case anymore. And
          though I can guess a couple reasons why, I found none to be qualified as an
          explanation.. Not in my book at least. Case you have any more questions, I'd
          be happy to answer. Building a site with director performance hints /
          optimizing lingo code is high in my to do list.


          "DaveGallant" <webforumsuser@macromedia.com> wrote in message
          news:g52c9u$31a$1@forums.macromedia.com...
          >I am having a problem with my program as I am not getting the desired frame
          > rate due to all the code that is getting executed per tick. So I have some
          > questions about director and lingo as to which way actually executes
          > faster.
          >
          > 1. Multiple ExitFrame calls vs a single ExitFrame
          > call.

          >
          > I have alot of sprites in my app. Almost all of them have an
          > ExitFrame
          > handler.
          > Question: is it faster to have each sprite handle it's own
          > ExitFrame
          > routine and do code specific to that sprite or is it faster to have one
          > generic
          > ExitFrame to loop through and execute code for each sprite?
          >
          > 2. Puppeted sprites vs Non-Puppeted sprites.
          >
          > I have a alot of sprites in my program. To make life ALOT easier, I simply
          > allocated a good chunk of sprite channels to sole use of "dynamically
          > created
          > sprites". My program can have hunders of puppeted sprites from any given
          > moment
          > to the next.
          > Question: Does director progress faster or slower depending on if a sprite
          > is
          > puppeted or not? Or is there any difference at all?
          >
          > 3. Checking to see if a variable is set before setting it.
          >
          > I have only recently come into the Director/Lingo world of programming. I
          > am
          > originally a VB programmer for almost a decade. In visual basic, I have
          > noticed
          > that the code executes faster if you don't do unneeded variable
          > assignments by
          > checking to see if it was already set.
          >
          > Example: In visual basic, let's say you have an array of 1000 elements,
          > some
          > elements are already set, some are not.
          >
          > for i = 1 to 1000
          > var(i) = i
          > next
          >
          > The above code executes fast, but if you are doing that very very often,
          > it
          > can be a bottle neck.
          > the below code, while doing the exact same thing, actually is faster.
          >
          > for i = 1 to 1000
          > if var(i) <> i then var(i) = i
          > next
          >
          > In VB, it's faster to do a check of a variable than it is to do the
          > assignment
          > when it's not needed. Now granted, this is a poor example, usually I am
          > dealing
          > with much more complex routines, but the basic principle of what I am
          > trying to
          > get across is the same.
          >
          > Question: in Director/lingo, would it speed up the execution of code to do
          > a
          > variable check before the assignment, or is the very act of adding the
          > check
          > going to slow the down the execution?
          >
          >
          >
          > Anyone have any ideas about these? Or anyone have any other tips about
          > stupid
          > little things to speed up execution of code?
          >


          • 2. Re: Optimizing Performance
            Production Monkey Level 3
            1. Delete any "updateStage()" commands. It is rarely necessary to tell the stage to redraw itself. Using this handler just wastes cpu cycles redrawing the screen.

            2. Delete any "prepareFrame()" handlers. This handler can force unnecessary screen redraws which suck up cpu cycles. Move your code to "beginSprite()" and/or "exitFrame()" handlers where the code belongs. There no need to ever use this handler.

            3. I doubt multiple exitFrame handlers cause any slow down. However, if those handlers are doing any time consuming processing, then you may see improvements if you change those handlers to "enterFrame()".

            4. Puppet/Non-Puppet? Can't imagine why that would make a difference to Director. A sprite is a sprite. Only using as many sprite channels as you need should help a bit. If you only use 200 channels, then don't set the number of channels to 1000.

            5. Set any DTS - Direct To Stage - members such as video, flash, and 3D to DTS.

            6. If you have more than one flash object on stage at a time then use the flash common player. Better yet, delete all the flash members.

            7. "repeat with Thing in aListOfThings" is the fastest way through a list. For property lists, access is fastest on sorted lists.

            8. Calculations that only need to be done once should be done on beginSprite() or new() and saved in properties.

            9. Always access members using cast name and member name. i.e. sprite(x).member = member("MemName","CastName"). Not only is this the fastest way to access members it makes debugging much easier. You could use member(5,8) but hard coding is a bad idea.

            There are other optimizations but they are specific to what your program does and the technologies it uses.

            As for "if var(i) <> i then var(i) = i" being slower or faster. Come on. I think you could run that test just as well as anyone here.
            • 3. Re: Optimizing Performance
              UdoGre Level 1
              quote:


              1. Multiple ExitFrame calls vs a single ExitFrame call.
              I have alot of sprites in my app. Almost all of them have an ExitFrame handler.


              Hi Dave,

              Move your code to enterframe instead (everything but the "go the frame" stuff) and your app will run much smoother.

              Director runs enterframe code (and stuff like stepframe), then sits there waiting while the time slice for one frame runs up, and executes exitframes handler once the time is already up! You can test this easily with a sample movie (run a repeat loop with 100 000 repeats on enterframe and another run on exitframe, and calculate the framerate. Put on idle, too).

              HTH,

              Udo
              • 4. Re: Optimizing Performance
                l2player Level 1
                quote:

                Originally posted by: Production Monkey

                2. Delete any "prepareFrame()" handlers. This handler can force unnecessary screen redraws which suck up cpu cycles. Move your code to "beginSprite()" and/or "exitFrame()" handlers where the code belongs. There no need to ever use this handler.


                • 5. Re: Optimizing Performance
                  l2player Level 1
                  The list 1 to 9 of Production Monkey as well as the messages of Alchemist and Udo have taught me a lot - thanks very much guys!

                  However, point 2 of Production Monkey is less clear to me. (I am sorry for quoting it in a wrong way). The reason why enterFrame would be "better" than prepareFrame, as I understand it, is as follows. If I issue the updateStage() command somewhere in my code, than, according to Director documentation, on prepareFrame handler will be called but on enterFrame handler will be not. And in this way only the enterFrame seems "safer" than prepareFrame.

                  Are there other reasons why enterFrame is "safer"? I do use sometimes prepareFrame in my code, because in my case there are advantages of doing certain things just before the stage is re-drawn.

                  And in the same way, the on StepFrame handler is as "unsafe" as on PrepareFrame, isn't it? Both are called if you issue an updateStage command.

                  Thank you.
                  • 6. Re: Optimizing Performance
                    Level 7
                    None of the handlers are "safer" than the others, but they serve
                    different purposes. enterFrame gets the largest slice of CPU time, so it
                    is a good place to put a lot of your commands. It beats out exitFrame
                    and prepareFrame simply because Director gives those handlers less CPU time.

                    There are some things that require prepareFrame, like moving a sprite to
                    match another sprite's location. It will look smoother on prepareFrame
                    so that makes prepareFrame the best choice there.

                    stepFrame is only for parent scripts, and unless you need to do
                    something immediately before or after all the stepFrame events, there is
                    not much use in using any other frame event for parents.

                    Sometimes the order that the events happen will matter... for example,
                    you may have a bunch of sprites that update their text on enterFrame,
                    then depending on what the text is, they change their locations on
                    exitFrame.

                    None of them are better than any others, they just serve different
                    purposes, though these purposes do greatly overlap...
                    • 7. Re: Optimizing Performance
                      Level 7
                      > enterFrame gets the largest slice of CPU time, so it is a good place to
                      > put a lot of your commands. It beats out exitFrame and prepareFrame
                      > simply because Director gives those handlers less CPU time.

                      Hey, Mike, where did you get that info from? And what do you mean by getting
                      larger slice, or less cpu time? These things have meaning for mulththreading
                      applications. Something that Director -better yet lingo- is not. For single
                      threaded apps, functions are executed sequentially. So, it's not about
                      slices, or what the processor gives.. It's how long each function will take.


                      "Mike Blaustein" <mblaustein@gmail.com> wrote in message
                      news:g58kkk$3pm$1@forums.macromedia.com...
                      > None of the handlers are "safer" than the others, but they serve different
                      > purposes. enterFrame gets the largest slice of CPU time, so it is a good
                      > place to put a lot of your commands. It beats out exitFrame and
                      > prepareFrame simply because Director gives those handlers less CPU time.
                      >
                      > There are some things that require prepareFrame, like moving a sprite to
                      > match another sprite's location. It will look smoother on prepareFrame so
                      > that makes prepareFrame the best choice there.
                      >
                      > stepFrame is only for parent scripts, and unless you need to do something
                      > immediately before or after all the stepFrame events, there is not much
                      > use in using any other frame event for parents.
                      >
                      > Sometimes the order that the events happen will matter... for example, you
                      > may have a bunch of sprites that update their text on enterFrame, then
                      > depending on what the text is, they change their locations on exitFrame.
                      >
                      > None of them are better than any others, they just serve different
                      > purposes, though these purposes do greatly overlap...


                      • 8. Re: Optimizing Performance
                        Level 7
                        Honestly. I don't remember where I heard it fro, but it was a long time
                        ago from one of the old masters, and it seems to hold true that my
                        framerates increase when I move processor intensive stuff from exitFrame
                        to enterFrame
                        • 9. Re: Optimizing Performance
                          Level 7
                          I take your word for the performance increase. But the only thing I can
                          think of that can justify this has nothing to do with 'slices' or 'cpu
                          favorite' handlers. Most probably, the method you are now following requires
                          one stage update less. It's easy to check, but I'd guess that anything not
                          related to the stage executes equally fast on any handler.

                          "Mike Blaustein" <mblaustein@gmail.com> wrote in message
                          news:g58nol$6ra$1@forums.macromedia.com...
                          > Honestly. I don't remember where I heard it fro, but it was a long time
                          > ago from one of the old masters, and it seems to hold true that my
                          > framerates increase when I move processor intensive stuff from exitFrame
                          > to enterFrame


                          • 10. Re: Optimizing Performance
                            l2player Level 1
                            Increase in performance after moving a heavy code from the exitFrame handler needs no proof. Udo Gre explained it in this thread, and the fact had been documented and explained in many places.

                            It appears that the code placed in StepFrame, prepareFrame and enterFrame handlers should each subsequently eat, with equal rate, as much CPU time as it takes to fully execute each of them.

                            The reasons why sometimes prepareFrame could be better than enterFrame, like in the example given by Mike of moving a sprite to match another sprite's location, are understandable. My question was the following. Let it is not important if my code will be executed before or after the stage is redrawn. Why then I should throw away prepareFrame, as Production Monkey has suggested. (Except the argument that prepareFrame catches updateStage commands while enterFrame ignores them).

                            Thanks very much.
                            Ilya Lad
                            • 11. Re: Optimizing Performance
                              multiduck Level 1
                              Directors calculatation on how long it should wait between frames to match your set framerate includes an estimation on how long it will take to run the code in enterframe but not for exitframe, which can lead to dropped frames with heavy exitframe scripts.
                              • 12. Re: Optimizing Performance
                                Production Monkey Level 3
                                I stopped using prepareFrame about 8 years ago when one of the gurus explained that before prepareFrame is called Director composites all the layers. If you move a sprite, or several, then Director re-composites the layers. In effect it is like calling updateStage twice. In addition to that, I remember having weird, unexplainable bugs pop up when using prepareFrame.

                                It could be that the guru was misinformed and my weird bugs were do to my inexperience, and there is actually no issue with using prepareFrame: but life has worked out just fine without ever using a prepareFrame ever again.

                                You should be able to write optimized Director programs by using a single exitframe handler to "go to the frame"; and beginSprite(), enterFrame(), and endSprite() for everything else.

                                If you get into Parent scripts then stepFrame or timeout objects enter the picture.

                                You can even toss out enterFrame and use timeout objects to update objects; escaping the limitations of a frame based system. This is what I do because it provides more flexibility, not necessarily any speed improvements. Some knowledge of OOP and manager objects would be helpful before dipping a toe in that pool.

                                "There are some things that require prepareFrame, like moving a sprite to
                                match another sprite's location. "

                                Mike, I guess I don't understand why you could not do that on enterFrame? Would you provide an example?
                                • 13. Re: Optimizing Performance
                                  Level 7
                                  > "There are some things that require prepareFrame, like moving a
                                  sprite to
                                  > match another sprite's location. "
                                  >
                                  > Mike, I guess I don't understand why you could not do that on enterFrame?
                                  > Would you provide an example?
                                  >

                                  It works just fine on enterFrame. But you will notice that the image
                                  lags behind a little when moving fast. The specific example I am
                                  thinking of is when you remove the cursor and set a sprite to follow the
                                  mouse (to make a custom cursor).

                                  on enterFrame me
                                  sprite(me.spriteNum).loc=the mouseLoc
                                  end

                                  Put that on any sprite. Press Play. Move the cursor around quickly and
                                  it lags a bit. Change the enterFrame handler to prepareFrame and the
                                  sprite matches the mouse movement better. The same thing happens if you
                                  are trying to match the motion of one sprite to the location of another
                                  sprite.
                                  • 14. Re: Optimizing Performance
                                    Production Monkey Level 3
                                    You have better eyes than I. The lag problem looks the same for prepareFrame and enterFrame to me.

                                    To each his own. There is no one-way to solve most problems in Director.

                                    • 15. Re: Optimizing Performance
                                      l2player Level 1
                                      Thank you all. Great and honest answers, Production Mokey and Mike Blaunstein! Your names sound so different :)

                                      I use stepFrame with a heavy code in it while (theoretically) being worried about the following. On certain frames it takes, say, 5 msec to run the code and on other frames it takes 20 msec. I cannot predict beforehand which of the two cases will happen. Let it always takes 10 msec to redraw the stage and then it remains nothing else to do on each frame, which each lasts 34msec. (So in between the EnterFrame and the exitFrame events it passes either 34-15 or 34-30 msec).

                                      Now, the frame timer is re-started regularly every 34 msec, but the on StepFrame handler consumes irregular time BEFORE the stage is refreshed. Therefore, I get irregular time intervals between the refreshes. My animation looks jerky!

                                      The effect would never happen if I placed that heavy code into the EnterFrame handler, which executes AFTER the refreshes. (The intervals between the EnterFrame and exitFrame would be irregular, but the interval between the refreshes of the stage would always be 34 msec).

                                      In this regard, the enterFrame seems "better".

                                      Still I use StepFrame. I hope the old guru told nothing bad about it to Production Monkey :) . Could you or Mike or anybody else comment on it, please ?
                                      • 16. Re: Optimizing Performance
                                        Level 7
                                        My opinion is to use the one that works best for you. There are always
                                        multiple ways of doing things, and I will commonly try the same code in
                                        different handlers to see which works best with the current project. If
                                        enterFrame works best and doesn't cause any problems, then it is the
                                        best solution.

                                        I use all of the frame handlers. I use stepFrame a whole lot for parent
                                        scripts, and most of my intense code that is not in parent scripts
                                        generally goes in enterFrame. But I still use prepareFrame and
                                        exitFrame for plenty of things.
                                        • 17. Re: Optimizing Performance
                                          DaveGallant Level 1
                                          I moved the bulk of my code to enterframe and this made a HUGE difference.

                                          I also cut down on the number of "enterframe" handlers and called methods manually to only preform processes when needing to, this also helped.

                                          Very good information all. Thanks alot.
                                          • 18. Re: Optimizing Performance
                                            Level 7
                                            Production Monkey wrote:
                                            > You have better eyes than I. The lag problem looks the same for prepareFrame and enterFrame to me.
                                            >
                                            > To each his own. There is no one-way to solve most problems in Director.
                                            >
                                            >
                                            Nope, Mike is all right! Chasing mouse using 'on prepareFrame' handler
                                            looks better, expecially in case of low framerates. This is because
                                            while 'on enterFrame' is executed, sprite positions were already fixed
                                            and no Lingo code can change it. The scene is drawn while the mouse is
                                            moving, so visible lag in sprite-to-mouse synchronisation. Any changes
                                            in sprite position calculated in 'on enterFrame' even will be drawn in
                                            the next frame!

                                            In a contrary - 'on PrepareFrame' event is fired prior final scene
                                            composition, so sprite position updates made in this moment can be
                                            reflected nearly immediately - in the very same frame. But the penalty
                                            is - in case execution of code in 'on prepareFrame' event takes too long
                                            - it will impact framerate significantly, as idle time between scene
                                            composition is pretty short - just a millisecond or two... This is
                                            opposite to 'on enterFrame' event, what is held after scene composition
                                            - it may use the long idle time since the scene is updated till 'on
                                            exitFrame' coming (again) just a few milliseconds prior next cycle.

                                            Rgs,
                                            Ziggi
                                            • 19. Re: Optimizing Performance
                                              Level 7
                                              Indeed!

                                              This issue affects keyPressed() game controls too.

                                              I must say I haven't noticed any problem at all using on exitframe for my 3D
                                              games, as long as you have director looping on a single frame. If the frame
                                              head is traversing the time line (ie. the 3D sprite is stretched along a
                                              looping time line), then the difference is huge.

                                              Cheers

                                              Richard
                                              www.funpods.com



                                              "Ziggi" <ziggi@z_i_g_g_i.pl> wrote in message
                                              news:g5gkof$qhg$1@forums.macromedia.com...
                                              > Production Monkey wrote:
                                              >> You have better eyes than I. The lag problem looks the same for
                                              >> prepareFrame and enterFrame to me. To each his own. There is no one-way
                                              >> to solve most problems in Director.
                                              >>
                                              >>
                                              > Nope, Mike is all right! Chasing mouse using 'on prepareFrame' handler
                                              > looks better, expecially in case of low framerates. This is because while
                                              > 'on enterFrame' is executed, sprite positions were already fixed and no
                                              > Lingo code can change it. The scene is drawn while the mouse is moving, so
                                              > visible lag in sprite-to-mouse synchronisation. Any changes in sprite
                                              > position calculated in 'on enterFrame' even will be drawn in the next
                                              > frame!
                                              >
                                              > In a contrary - 'on PrepareFrame' event is fired prior final scene
                                              > composition, so sprite position updates made in this moment can be
                                              > reflected nearly immediately - in the very same frame. But the penalty
                                              > is - in case execution of code in 'on prepareFrame' event takes too long -
                                              > it will impact framerate significantly, as idle time between scene
                                              > composition is pretty short - just a millisecond or two... This is
                                              > opposite to 'on enterFrame' event, what is held after scene composition -
                                              > it may use the long idle time since the scene is updated till 'on
                                              > exitFrame' coming (again) just a few milliseconds prior next cycle.
                                              >
                                              > Rgs,
                                              > Ziggi


                                              • 20. Re: Optimizing Performance
                                                l2player Level 1
                                                Ziggi wrote: " idle time between scene composition is pretty short - just a millisecond or two..."

                                                Ziggi, what do you mean by idle time between scene composition?

                                                Let there are nearly no code in the prepareFrame handler and let the stage is redrawn instantly. Then, as far as I see, essentially zero time elapses between the prepareFrame and enterFrame events. There is no any "idle" time between them. And this is in agreement with Director documentation.

                                                Note: in testing my statement it is important not to output something into the message window between the PrepareFrame and enterFrame events.
                                                • 21. Re: Optimizing Performance
                                                  enrique_rodriguez Level 1
                                                  Hi folks, i would like to share a technique that i use. The reason for me to use it isn' t the same for you, but here it goes.

                                                  First, I create a parent script that work only as a stepframe updater, it is like:
                                                  script: "stepper"

                                                  property pBoss

                                                  on new me, aBoss
                                                  pBoss = aBoss
                                                  add(the actorList, me)
                                                  end new

                                                  on stepFrame me
                                                  pBoss.stepFrame()
                                                  end stepFrame

                                                  then, in the main script, i create an child:

                                                  script: "main"

                                                  on beginSprite me
                                                  new (script "stepper", me)
                                                  end beginSprite

                                                  on stepFrame me
                                                  --código a ejecutar
                                                  end stepFrame

                                                  I dont need a exitframe, prepareframe, enterframe, etc.
                                                  of course, you do not forget to call clearglobals in stopmovie.

                                                  I hope it helps.
                                                  • 22. Re: Optimizing Performance
                                                    pete.h Level 1
                                                    Some good optimization tips here:
                                                    http://blurredistinction.com/director/tips.htm