realbasic-nug
[Top] [All Lists]

Re: Performance and faster idioms

To: "REALbasic NUG" <realbasic-nug at lists dot realsoftware dot com>
Subject: Re: Performance and faster idioms
From: "Salvetti2" <salvetti at salvetti dot com>
Date: Sun, 27 Feb 2005 22:10:57 -0700
Delivered-to: realbasic-nug at lists dot realsoftware dot com
References: <BE474E14 dot 629D4%mars at realsoftware dot com> <828CF2C8-8911-11D9-83BF-000A957CB4CC at desuetude dot com>
Hi Charles,
There is a problem with this metrics.
A great deal of time wasted in the loop goes for "FOR..NEXT" and "RND"
instructions.
So, if you just take a ratio between the two implementations, you have:
(loop_setup_cycles + "case" block cycles)  /   (loop_setup_cycles + "if"
block cycles)

So (k + a) / (k + b) is not equal to a / b

This is even worse if the number of cycles is too large, because the limit
of the ratio goes to "1" and you have the false idea that a/b=1 and
therefore a=b

You have to consider loop_setup_cycles as a baseline that you need to
subtract from the total number of cycles wasted by the each implementation.

When you do:
actual case blocks cycles = total case loop cycles  - loop_setup_cycles
actual if blocks cycles = total if loop cycles  - loop_setup_cycles

and then take the ratio:
actual case blocks cycles / actual if blocks cycles
you get "3" , suggesting that the "if" implementation is 3 times faster than
the "case" implementation for that test case.

In order to find the baseline, the loop_setup_cycles, just run the loop
without the if/case blocks, as in:

    dim i as Integer
    dim x as Integer

    #pragma DisableBackgroundTasks
    For i = 0 to 100000
      x = Rnd*10
    Next

Make sure to increase the number of interactions to something bigger than
100000 (too short and might give you less than 1 tick depending on your
computer).

Arthur Salvetti


----- Original Message ----- 
From: "Charles Yeomans" <yeomans at desuetude dot com>
To: "REALbasic NUG" <realbasic-nug at lists dot realsoftware dot com>
Sent: Sunday, February 27, 2005 3:47 PM
Subject: Re: Performance and faster idioms


>
> On Feb 27, 2005, at 1:14 PM, Mars Saxman wrote:
>
> > enter at rovosoft dot com wrote:
> >
> >> Hi all,
> >>
> >> Being a sucker for speed, I tried to find something to back my
> >> assumptions, which I found in one of the SlayFire rules. It says the
> >> use
> >> of an If block is on average 150,000% faster than a select case...
> >
> > Well, as with anything performance related, don't just take someone
> > else's
> > word for it: test it in your application both ways and find out which
> > way
> > actually works faster in your situation.
> >
> > I have heard this "150,000%" number before, and I am extremely
> > skeptical;
> > Select Case and If-Then boil down to almost the same thing internally,
> > and I
> > cannot see anything that would account for such a dramatic performance
> > penalty. The only difference I can think of actually points in Select's
> > favor, since it only has to evaluate the test expression once.
>
>
> My testing suggests that Select Case blocks are slower than If blocks,
> but not by that much.  Here's my test code.
>
> Sub TestSelect()
>    dim i as Integer
>    dim x as Integer
>
>    #pragma DisableBackgroundTasks
>    For i = 0 to 100000
>      x = Rnd*10
>      Select Case x
>      Case 0
>      Case 1
>      Case 2
>      Case 3
>      Case 4
>      Case 5
>      Case 6
>      Case 7
>      Case 8
>      Case 9
>      Else
>      End Select
>    Next
> End Sub
>
> Sub TestIf()
>    dim i as Integer
>    dim x as Integer
>
>    #pragma DisableBackgroundTasks
>    For i = 0 to 100000
>      x = Rnd*10
>      If x = 0 Then
>      Elseif x = 1 the
>      Elseif x = 2 then
>      Elseif x = 3 then
>      Elseif x = 4 then
>      Elseif x = 5 then
>      Elseif x = 6 then
>      Elseif x = 7 then
>      Elseif x = 8 then
>      Elseif x = 9 then
>      Else
>      End if
>    Next
> End Sub
>
> TestIf took about 11 ticks v. 13 ticks for TestSelect.  So on average
> either block is executing in less than 2 microseconds.  I'll tackle
> that bottleneck later.
>
> This led me to wonder about other optimization tips on the Slayfire web
> site.  Technique # 59, the only one I found, says to consider using
> (X\1) + 1 in lieu of Ceil(X), as "Using division is much faster than
> using Ceil".  The web site claims an 1800% difference.  So I wrote a
> simple test.  According to my test, Ceil is actually slightly faster
> than X\1 + 1; the difference is on the order of 10 ticks per 100000
> iterations.
>
>
> Charles Yeomans
>
> _______________________________________________
> 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>

<Prev in Thread] Current Thread [Next in Thread>