I've just noticed something interesting.
If you run Charles' code through the debugger, you get it 3x faster for the
"if" block (if you subtract the loop overhead, 2x faster if you don't
subtract the overhead).
If you compile the code and run the .exe file, you get the same speed for
both blocks! (I'm running it on Windows XP)
Arthur Salvetti
----- Original Message -----
From: "Brady Duga" <duga at ljug dot com>
To: "REALbasic NUG" <realbasic-nug at lists dot realsoftware dot com>
Sent: Monday, February 28, 2005 12:12 AM
Subject: Re: Performance and faster idioms
> And, to add a little more to the discussion, I decided to see what was
> really going on. I made the following 2 methods:
>
> Protected Sub Test1()
> dim x as Integer
> if x= 0 then
> elseif x=1 then
> elseif x= 2 then
> else
> end if
> End Sub
>
> Protected Sub Test2()
> dim x as Integer
> Select case x
> case 0
> case 1
> case 2
> else
> end Select
> End Sub
>
> and built the app, with symbols on. I then took a look at them
> side-by-side in PEF Viewer. The interesting thing this revealed, other
> than how poor my knowledge of PPC assembly is, was a distinct lack of
> any difference. As far as I can see, the generated code is identical
> for both cases.
>
> Just for giggles, I built Charles' code. In his code, he has an else
> statement at the end which was missing from my code. In this case, the
> code is *almost* identical. The only real difference I note is an
> additional branch instruction, aside from some other minor offsets for
> jumps (makes sense, since there is that extra instruction in the way).
> In the select case, we see:
>
> 234: branch if equal to 23C
> 238: branch to 240
> 23C: branch to 240
> 240: ...
>
> and in the if case:
>
> 234: branch if equal to 23C
> 238: branch to 23C
> 23C: ...
>
> Note that in both cases these jumps appear useless, since, no matter
> what, you will end up at 240/23C. However, it makes more sense if you
> consider 240 is just past the select or if. Since there is no other
> code in there, the jumps don't actually go anywhere. By adding a line
> of code to every block, we see that the if cases do their stuff, then
> jump past the end of the if. The final else clause does not jump,
> rather it realizes it is at the end of the if statement and just falls
> thru. In the select case, everything is the same except there is a
> final branch at the end of the else clause, to just past the end of the
> select block, which is of course the very next line. So, the difference
> appears to be that a final else clause in a series of if/elseif
> statments is smart enough to not require an extra jump. As far as
> performance, this should only matter in the case where you end with an
> else. Even then, you would need to hit the else clause quite often for
> it to make any difference.
>
> As for the various time differences, I could see (possibly) how a
> specially crafted test case could result in the select taking 2x longer
> (say, when the else clause is always the only one hit), though even
> that seems unlikely. Not sure how or why people are seeing such large
> differences (200%, 300%, 150,000% ...).
>
> OK, now I'm going to bed, which I probably should have done instead of
> looking at this.
>
> --Brady
> The La Jolla Underground
>
> _______________________________________________
> 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>
|