Xojo Conferences
XDCMay2019MiamiUSA

Code optimization for speed (Real Studio games Mailinglist archive)

Back to the thread list
Previous thread: Renegades navnode triggers (was: unwanted X-ray vision)
Next thread: [Slightly OT] X Box


Code optimization for speed   -   Heinz J. Gattringer
  Re: Code optimization for speed   -   Scott Duensing
  Re: Code optimization for speed   -   Lars Jensen
  Re: Code optimization for speed   -   Heinz J. Gattringer
   Re: Code optimization for speed   -   Lars Jensen

Code optimization for speed
Date: 04.01.05 21:21 (Tue, 4 Jan 2005 15:21:57 -0500)
From: Heinz J. Gattringer
Greetings all
Still working on my RTS-kind of game. Although in early development
yet, I have quite a number of sprites in my game which have their
behavior controlled by their own A.I. There are of course multiple ways
of achiveing 'smart' descision making. In order to optimize the speed
of the execution of the code I wonder about the "internal" efficiency
of some commands. To be concrete:
Is it more efficient to have an If-Then branching 2 or 3 levels deep or
a rather complicated single line algorythmus with something like 9 to
12 elements which include sums, multiplications, divisions and even
trigonometrical functions?

I understand that if-then comparisons are rather slow (yet the
resulting code is much clearer to troubleshoot and tweak), but the
algorythmus seems rather heavy, too (and rather messy to tweak). Bear
in mind that these logics/calculations get to be done (I hope) some 25
times per second and for many diferent objects in the game, so even a
slight speed gain can be significant. And I am aiming for low end
target systems.

Thanks for any ideas.

Heinz Jose

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Code optimization for speed
Date: 05.01.05 04:27 (Tue, 04 Jan 2005 21:27:40 -0600)
From: Scott Duensing
I would think in the long run that the IF block would be most efficient.
One thing you may want to consider is breaking the logic up into
multiple steps using a state machine. Odds are, you don't need to
process all the data on every frame - use the state machine to do a
little bit of the work during each frame. Break it into smaller,
logical, chunks and do the job across five or six frames.

Scott


Heinz J. Gattringer wrote:
> Greetings all
> Still working on my RTS-kind of game. Although in early development yet,
> I have quite a number of sprites in my game which have their behavior
> controlled by their own A.I. There are of course multiple ways of
> achiveing 'smart' descision making. In order to optimize the speed of
> the execution of the code I wonder about the "internal" efficiency of
> some commands. To be concrete:
> Is it more efficient to have an If-Then branching 2 or 3 levels deep or
> a rather complicated single line algorythmus with something like 9 to 12
> elements which include sums, multiplications, divisions and even
> trigonometrical functions?
>
> I understand that if-then comparisons are rather slow (yet the resulting
> code is much clearer to troubleshoot and tweak), but the algorythmus
> seems rather heavy, too (and rather messy to tweak). Bear in mind that
> these logics/calculations get to be done (I hope) some 25 times per
> second and for many diferent objects in the game, so even a slight speed
> gain can be significant. And I am aiming for low end target systems.
>
> Thanks for any ideas.
>
> Heinz Jose
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
> Search the archives of this list here:
> <http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Code optimization for speed
Date: 05.01.05 05:03 (Tue, 04 Jan 2005 23:03:21 -0500)
From: Lars Jensen
> Is it more efficient to have an If-Then branching 2 or 3 levels deep or
> a rather complicated single line algorythmus with something like 9 to
> 12 elements which include sums, multiplications, divisions and even
> trigonometrical functions?

I have no idea; I would expect it to depend heavily on the details of the
calculations and of the machines you're running on, not to mention the
specifics of how you write RB code.

I can barely remember where I put the cat food, so devoting precious neurons
to processor details is right out. Instead, I write a test driver for
time-critical code, and keep it independent of the display. Then I can
fiddle with the algorithms and know whether I'm making them faster or slower
(as well as whether I've broken them entirely).

lj

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Code optimization for speed
Date: 05.01.05 20:56 (Wed, 5 Jan 2005 14:56:44 -0500)
From: Heinz J. Gattringer

On Jan 5, 2005, at 1:00 PM,
<email address removed> wrote:
>
> I would think in the long run that the IF block would be most
> efficient.
> One thing you may want to consider is breaking the logic up into
> multiple steps using a state machine. Odds are, you don't need to
> process all the data on every frame - use the state machine to do a
> little bit of the work during each frame. Break it into smaller,
> logical, chunks and do the job across five or six frames.
>
> Scott
>

Glad you think so, because the IF-Then block sure seems more
"programmer-friendly" to me than brain-numbing complex calculations.
Specially if you leave the project for a week or more and come back to
it later and are not mentally "up to date".

I started in fact to have some code get processed only ever so often,
not everytime, but that would be a second optimization step I plan to
do more intensely later, after getting this first step 'cleared'.

>
> I have no idea; I would expect it to depend heavily on the details of
> the
> calculations and of the machines you're running on, not to mention the
> specifics of how you write RB code.
>
> I can barely remember where I put the cat food, so devoting precious
> neurons
> to processor details is right out. Instead, I write a test driver for
> time-critical code, and keep it independent of the display. Then I can
> fiddle with the algorithms and know whether I'm making them faster or
> slower
> (as well as whether I've broken them entirely).
>
> lj

Not quite sure what you mean by keeping it independent of the display
(you mean timing only the A.I. logic, not the screen drawing, which
might be very influenced by the hardware configuration?).
I have a very simple time gauge (or Frames per Second counter if you
wish) implemented. Basically I store the microseconds in a variable,
call spritesurface.update, handle some of the interface homework and
then display the transpired microseconds shortly before calling
spritesurface.update again. Not very sophisticated but it works.
With about 20% of the intended elements running I have already
'saturated' about 55% of my time allowance per cycle, hence the
question on speed optimization of code.
Trial and error is certainly a way to go here, but I first wanted to
get some pointers from more experienced programmers before investing a
lot of time in code rewrites or test runs. Who knows, you always might
learn something unexpected or completely from left outfield.

Thanks for the answers so far.
Heinz Jose
P.S. Hope you had fine, code free vacations Joe.

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

Re: Code optimization for speed
Date: 05.01.05 22:18 (Wed, 05 Jan 2005 16:18:44 -0500)
From: Lars Jensen
> Not quite sure what you mean by keeping it independent of the display
> (you mean timing only the A.I. logic, not the screen drawing, which
> might be very influenced by the hardware configuration?).

Exactly.

> I have a very simple time gauge (or Frames per Second counter if you
> wish) implemented. Basically I store the microseconds in a variable,
> call spritesurface.update, handle some of the interface homework and
> then display the transpired microseconds shortly before calling
> spritesurface.update again. Not very sophisticated but it works.

That's good too, but different than the above. Basically, once I know that I
have to make something faster, I like to isolate it so I have a good idea
just how much faster I have made it.

I might think "OK, this should speed things up", only see no discernible
effect. Is that because I was wrong about the potential for speedup, or
might I have a bug somewhere? With an isolated tester, I can eliminate the
display system as a suspect.

lj

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>