Visual Basic - What is faster?

Author

What is faster?

Sami

2005-08-25, 6:55 pm

Hello,

Which one of these is faster:
#######################
1) Inside a Loop:
If bResult = False Then // Is it faster to check the Boolean value
for a "FALSE" and set it once
bResult = True
End if

OR

2) Inside a Loop:
If bResult = True Then
lCounter = lCounter + 1 // is it faster to check the Boolean value
for a "TRUE"and increment a Long variable?
End if
########################

This is just for reference and does not pertain to my question above.
Outside the Loop after it has run:
(for Option 1)
If bResult = False Then
Save( )
End if

(for Option 2)
If lCounter = 0 Then
Save( )
End if

My guess is that 1 is faster.
--
Regards,
Sami

[Remove Numbers from e-mail address to use it]

Dave

2005-08-25, 6:55 pm

Hi

Why not make a little program which goes through each loop a few hundred
thousand times, and see which one is actually faster. If you can't determine
a difference then it doesn't matter.

Once you have that framework you can drop any pair of routines in to compare
them. A useful tool if you are worried about getting your work to run as
fast as possible.

Dave.

"Sami" <s8a2m9i1_i5s1l9a6m@hotmail.com> wrote in message
news:%23WeehXXqFHA.208@TK2MSFTNGP10.phx.gbl...
> Hello,
>
> Which one of these is faster:
> #######################
> 1) Inside a Loop:
> If bResult = False Then // Is it faster to check the Boolean value
> for a "FALSE" and set it once
> bResult = True
> End if
>
> OR
>
> 2) Inside a Loop:
> If bResult = True Then
> lCounter = lCounter + 1 // is it faster to check the Boolean value
> for a "TRUE"and increment a Long variable?
> End if
> ########################
>
> This is just for reference and does not pertain to my question above.
> Outside the Loop after it has run:
> (for Option 1)
> If bResult = False Then
> Save( )
> End if
>
> (for Option 2)
> If lCounter = 0 Then
> Save( )
> End if
>
>
> My guess is that 1 is faster.
> --
> Regards,
> Sami
>
> [Remove Numbers from e-mail address to use it]
>
>

Ralph

2005-08-25, 6:55 pm

"Dave" <Nobody@Nowhere.Com> wrote in message
news:%23du9dgXqFHA.1040@tk2msftngp13.phx.gbl...
> Hi
>
> Why not make a little program which goes through each loop a few hundred
> thousand times, and see which one is actually faster. If you can't
determine
> a difference then it doesn't matter.
>
> Once you have that framework you can drop any pair of routines in to
compare
> them. A useful tool if you are worried about getting your work to run as
> fast as possible.
>
> Dave.
>
> "Sami" <s8a2m9i1_i5s1l9a6m@hotmail.com> wrote in message
> news:%23WeehXXqFHA.208@TK2MSFTNGP10.phx.gbl...
value[color=darkred]
>

Excellent advice. One should always measure if its really that important.

The biggest problem with "Thought Performance Tuning" on code snippets is
that the major impact on performance usually comes from the overall
algorithm and the real bottlenecks are seldom where you 'think' they are
before you test.

-ralph

Duane Bozarth

2005-08-25, 6:55 pm

Ralph wrote:
>
> "Dave" <Nobody@Nowhere.Com> wrote in message
> news:%23du9dgXqFHA.1040@tk2msftngp13.phx.gbl...
....
[color=darkred]
> Excellent advice. One should always measure if its really that important.
>
> The biggest problem with "Thought Performance Tuning" on code snippets is
> that the major impact on performance usually comes from the overall
> algorithm and the real bottlenecks are seldom where you 'think' they are
> before you test.
>
> -ralph

Also when testing timing, particularly in an environment such as VB,
don't forget to test the compiled code as well as in the IDE--results
may be different...

Hal Rosser

2005-08-25, 6:55 pm

I'm not sure which is faster, but aren't you being redundant by checking if
the boolean = true or false ?
A boolean stands by itself as a condition.

If bResult Then
'//## Do something
End If

"Sami" <s8a2m9i1_i5s1l9a6m@hotmail.com> wrote in message
news:%23WeehXXqFHA.208@TK2MSFTNGP10.phx.gbl...
> Hello,
>
> Which one of these is faster:
> #######################
> 1) Inside a Loop:
> If bResult = False Then // Is it faster to check the Boolean value
> for a "FALSE" and set it once
> bResult = True
> End if
>
> OR
>
> 2) Inside a Loop:
> If bResult = True Then
> lCounter = lCounter + 1 // is it faster to check the Boolean value
> for a "TRUE"and increment a Long variable?
> End if
> ########################
>
> This is just for reference and does not pertain to my question above.
> Outside the Loop after it has run:
> (for Option 1)
> If bResult = False Then
> Save( )
> End if
>
> (for Option 2)
> If lCounter = 0 Then
> Save( )
> End if
>
>
> My guess is that 1 is faster.
> --
> Regards,
> Sami
>
> [Remove Numbers from e-mail address to use it]
>
=======================================
I'm not sure which is faster, but aren't you being redundant by checking if
the boolean = true or false ?
A boolean stands by itself as a condition after the 'if' keyword.

If bResult Then
'//## Do something when the variable is true
End If
===============================

MikeD

2005-08-25, 9:55 pm

Hal Rosser

2005-08-26, 9:55 pm

"MikeD" <nobody@nowhere.edu> wrote in message
news:e%23M6DQdqFHA.564@TK2MSFTNGP10.phx.gbl...
>
> "Hal Rosser" <hmrosser@bellsouth.net> wrote in message
> news:enqPe.540$7F.510@bignews3.bellsouth.net...
> if
>
>
> There's still an implicit comparison being done. There's no measureable
> difference between 'If bResult Then' and 'If bResult = True Then'. For
that
> matter, they might even compile identically.
>
> If you really want to be nitpicky, your statement that a boolean stands by
> itself as a condition is really rather limiting. So can a Long, or an
> Integer, or anything else. The following is valid code:
>
> Dim A As Long
> If A Then
> 'Do something
> End If
>
> --
> Mike
> Microsoft MVP Visual Basic

I accept your statement as gospel, in that there is no measurable difference
with or without the "= True" after a boolean variable in an "If" statement.
You are probably more experienced than me and probably can program circles
around me, - but I still think that adding "= True" after a boolean
variable in an "If" statement is being redundant. That is just my opinion -
and I probably will not change it in the near future. Giving the variable a
name beginning with "is" also goes along with this 'philosophy'.

If blnIsValidEmail Then
'#// yadda yadda
End If

Your example of using a numeric variable as a boolean condition made me
shudder. :-)

Duane Bozarth

2005-08-26, 9:55 pm

Hal Rosser wrote:
>
> "MikeD" <nobody@nowhere.edu> wrote in message
> news:e%23M6DQdqFHA.564@TK2MSFTNGP10.phx.gbl...
> that
>
> I accept your statement as gospel, in that there is no measurable difference
> with or without the "= True" after a boolean variable in an "If" statement.
> You are probably more experienced than me and probably can program circles
> around me, - but I still think that adding "= True" after a boolean
> variable in an "If" statement is being redundant. That is just my opinion -
> and I probably will not change it in the near future. Giving the variable a
> name beginning with "is" also goes along with this 'philosophy'.
>
> If blnIsValidEmail Then
> '#// yadda yadda
> End If
>
> Your example of using a numeric variable as a boolean condition made me
> shudder. :-)

You're mistaking (or at least mixing up) the difference between source
statements and the implementation of that source code into machine
instructions.

From the standpoint of <source>, yes, you can consider the "=Value"
portion of a Boolean test as redundant or superfluous. But, as Mike is
pointing out, what has to happen for that test to be performed is for
that source code to be translated into machine instructions.

What is required for the proper evaluation of the expression "If bVar
Then" is that for any non-zero value of vBar the following construct
statements are to be executed. That is and can only be done by the
compiler evaluating the condition

If vBar <> 0 Then

Thus, the condition is actually compiled, probably into a BNE machine
instruction (although I've not actually looked at VB compiler-generated
code to verify which way it builds If...Then constructs). For that BNE
instruction there also is a register value it's compared against.

So, the point of all the above rather long-winded rambling is to remind
you to not equate brevity of <source code> with necessarily shorter
(either in size or speed) compiled code.

HTH...

MikeD

2005-08-26, 9:55 pm

"Hal Rosser" <hmrosser@bellsouth.net> wrote in message
news:A%NPe.5523$N1.2827@bignews4.bellsouth.net...
>
> "MikeD" <nobody@nowhere.edu> wrote in message
> news:e%23M6DQdqFHA.564@TK2MSFTNGP10.phx.gbl...
by[color=darkred]
> Your example of using a numeric variable as a boolean condition made me
> shudder. :-)

I didn't say it was good code. I said it was valid code. There's a
difference.

That code is really this:

If A <> 0 Then

Would you shudder at that also? My guess would be probably not. But your
"argument" suggests that this 2nd way of writing that code is being
redundant (because the '<> 0' part isn't really needed).

Personally, I would not consider that 'If A Then' statement as being "good"
code either. Not because there's really anything wrong with it, but just
because it's not quite as clear.

--
Mike
Microsoft MVP Visual Basic

Larry Serflaten

2005-08-26, 9:55 pm

"MikeD" <nobody@nowhere.edu> wrote

> if
>
>
> There's still an implicit comparison being done. There's no measureable
> difference between 'If bResult Then' and 'If bResult = True Then'. For that
> matter, they might even compile identically.

FWIW: I'd disagree with that statement. Taken to some large extreme, there
is a measurable difference. There has even been a 'best practices' paper indicating
that the shorter form is often the better form to use. (May have been for .Net, I
can't find it now)

It would be more accurate to say the differences are negligable for most situations.

LFS

Compile and run...

Private Sub Form_Load()
Dim i As Long
Dim t As Double
Show
AutoRedraw = True

t = CDbl(Timer)
For i = 0 To 500000
TestFull
Next
t = CDbl(Timer) - t
Print "If X = Y", t

t = CDbl(Timer)
For i = 0 To 500000
Testhalf
Next
t = CDbl(Timer) - t
Print "If X ", t

End Sub

Private Sub TestFull()
Dim a As Long, b As Boolean
b = True
If b = True Then a = a + 1
If b = True Then a = a - 1
If b = True Then a = a + 1
If b = True Then a = a - 1
If b = True Then a = a + 1
If b = True Then a = a - 1
If b = True Then a = a + 1
If b = True Then a = a - 1
If b = True Then a = a + 1
If b = True Then a = a - 1
b = False
If b = True Then a = a + 1
If b = True Then a = a - 1
If b = True Then a = a + 1
If b = True Then a = a - 1
If b = True Then a = a + 1
If b = True Then a = a - 1
If b = True Then a = a + 1
If b = True Then a = a - 1
If b = True Then a = a + 1
If b = True Then a = a - 1
End Sub

Private Sub Testhalf()
Dim a As Long, b As Boolean
b = True
If b Then a = a + 1
If b Then a = a - 1
If b Then a = a + 1
If b Then a = a - 1
If b Then a = a + 1
If b Then a = a - 1
If b Then a = a + 1
If b Then a = a - 1
If b Then a = a + 1
If b Then a = a - 1
b = False
If b Then a = a + 1
If b Then a = a - 1
If b Then a = a + 1
If b Then a = a - 1
If b Then a = a + 1
If b Then a = a - 1
If b Then a = a + 1
If b Then a = a - 1
If b Then a = a + 1
If b Then a = a - 1
End Sub

MikeD

2005-08-26, 9:55 pm

"Larry Serflaten" <serflaten@usinternet.com> wrote in message
news:%23aWq4pqqFHA.3788@TK2MSFTNGP12.phx.gbl...
>
> "MikeD" <nobody@nowhere.edu> wrote
>
checking[color=darkred]
that[color=darkred]
>
> FWIW: I'd disagree with that statement. Taken to some large extreme,
there
> is a measurable difference.

OK. Maybe I should have said perceivable difference instead of measureable
difference. <g>

FWIW, I tried your benchmark test. Kind of interesting. Here are the
results of running it:

If X = Y 0
If X 1.00000000093132E-02

If I'm not mistaken, the above results indicate that Testhalf took longer
than TestFull. And yes, I compiled it as you said and ran the EXE. In any
event, the difference is SO negligible that clarity of the code should be
more important. Wouldn't you agree?

Now I did make a minor change in Form_Load, but it should not have affected
the results. I just changed it to to assign to a textbox rather than print
in on the form (so I could copy and paste).

Private Sub Form_Load()
Dim i As Long
Dim t As Double
Dim Result As String

Show
AutoRedraw = True

t = CDbl(Timer)
For i = 0 To 500000
TestFull
Next
t = CDbl(Timer) - t
Result = "If X = Y" & vbTab & t & vbCrLf

t = CDbl(Timer)
For i = 0 To 500000
Testhalf
Next
t = CDbl(Timer) - t
Result = Result & "If X " & vbTab & t

Text1.Text = Result

End Sub

Larry Serflaten

2005-08-27, 7:55 am

"MikeD" <nobody@nowhere.edu> wrote

> If I'm not mistaken, the above results indicate that Testhalf took longer
> than TestFull. And yes, I compiled it as you said and ran the EXE. In any
> event, the difference is SO negligible that clarity of the code should be
> more important. Wouldn't you agree?

Definately.

LFS

Gerald Hernandez

2005-08-27, 6:55 pm

"Hal Rosser" <hmrosser@bellsouth.net> wrote in message
news:enqPe.540$7F.510@bignews3.bellsouth.net...
> I'm not sure which is faster, but aren't you being redundant by checking
if
> the boolean = true or false ?
> A boolean stands by itself as a condition.
>
> If bResult Then
> '//## Do something
> End If

Ok, I know I'm proly gonna regret this...
I am known for being overly explicit. My coding standards require that there
be no ambiguity, even if the result may be considered "obvious". Therefore,
I would consider "If bResult Then" to be unacceptable and require an
explicit test "If bResult = True Then".
I was taken to task on this by someone who insisted that my way was less
efficient and actually required 2 tests. Therefore I was forced to prove my
point.

Below is the VB Source, the assembly language generated (edited to be
readable within context), and the resulting VB "behaviour":
VB:
If bResult Then
ASM:
;Compare bResult to False
cmp bResult, 0
;Fail test or Jump out if values ARE Equal
je [address]
Behaviour:
If bResult = FALSE, then fail

VB:
If bResult = True Then
ASM:
;Compare bResult to True
cmp bResult, -1
;Fail test or Jump out if values NOT Equal
jne [address]
Behaviour:
If bResult <> TRUE, then fail

Note the only differences are the comparison value and the jump behaviour.
We all know a logical test must take place anyway. However, no "additional"
test is necessary. There are exactly the same number of Assembly
instructions, and neither is more or less computationally expensive than the
other.

While many times we don't give the VB compiler enough credit, on occasion we
give it too much credit. On more than one occasion I have had VB parse a
seemingly obvious line of source incorrectly and give me the wrong results.
But in a another compile it parses it correctly. Ambiguity, however slight,
should be avoided.
Therefore, since explicitly comparing the values to the desired result
eliminates ambiguity, and is not more computationally expensive, then I
propose that it is more "efficient" in the long term.

Now, I'm not SO anal as to ding someone for something like:
If bIsEmailValid(EmailString) Then

And truth be known, I just might do that myself.
But if they perform an explicit test they might get brownie points :-)

Gerald

Hal Rosser

2005-08-27, 6:55 pm

If the name of the boolean variable is "blnResult" - then adding "= True"
after it would make the code clearer - I agree and concede to that case..
But if the name of the variable is something like "isValidStudentID" the "=
True" would not be required.

If isValidStudentID Then
'//#//// process the student id
End If

So we all agree that the code needs to be clear.
And I concede a little - based on the name of the variable. (But the name of
the variable is the reason.)
So - naming variables may be another topic for discussion.

Larry Serflaten

2005-08-27, 6:55 pm

"Hal Rosser" <hmrosser@bellsouth.net> wrote

> So we all agree that the code needs to be clear.

Agreed.

> So - naming variables may be another topic for discussion.

I'll pass on that topic. I've been at it over 20 years, I've already
determined what works best for me! :-)

LFS

Gerald Hernandez

2005-08-28, 3:55 am

"Hal Rosser" <hmrosser@bellsouth.net> wrote in message
news:jT2Qe.10504$HM2.23@bignews5.bellsouth.net...
>
> If the name of the boolean variable is "blnResult" - then adding "= True"
> after it would make the code clearer - I agree and concede to that case..
> But if the name of the variable is something like "isValidStudentID" the
"=
> True" would not be required.
>
> If isValidStudentID Then
> '//#//// process the student id
> End If
>
> So we all agree that the code needs to be clear.
> And I concede a little - based on the name of the variable. (But the name
of
> the variable is the reason.)
> So - naming variables may be another topic for discussion.
>

Well, technically there's nothing wrong with that. However, in my group it
wouldn't fly.
Looking at that particular line, out of context of course, I don't know if
that is a Boolean or not, I can only assume. Even with Boolean, there are 2
possible states. Which in particular are you interested in? Given there is
no indication of the variable type in it's name, we can only hope. I
often-times explicitly test for False as well. Maybe the missing value is an
oversight and it was supposed to be there.

If you are the only one maintaining your code, you know your way of doing
things. In my case, many other people may see the final code and it may be
their responsibility to maintain it. So, I still think being overly explicit
is better for me. In practice, I have found that if you have an incorrect
but explicit comparison, your are much more likely to notice that in QC or
while debugging. While without it, you tend to skip over that line over and
over without noticing it.

heh, variable naming is quite a topic. Personally, I'm not all that partial
to the variable type prefixes, such as "bln". But it really depends on the
situation, sometimes it helps maintain the code, and reduce ambiguity ;-)
So I suppose I don't have much constructive to add to that topic.

My goal is not to convince anyone "my way" is better or anything like that.
The key point is, that in this case, there are no negative ramifications for
being more explicit.

Gerald

Dave

2005-08-30, 7:55 am

> VB:
> If bResult = True Then
> ASM:
> ;Compare bResult to True
> cmp bResult, -1
> ;Fail test or Jump out if values NOT Equal
> jne [address]
> Behaviour:
> If bResult <> TRUE, then fail

Are you sure about this?
I don't think "cmp bResult, -1" would work as ANY non-zero value is treated
as true.

Regards
dave

Duane Bozarth

2005-08-30, 6:55 pm

Dave wrote:
>
>
> Are you sure about this?
> I don't think "cmp bResult, -1" would work as ANY non-zero value is treated
> as true.

Only if the explicit comparison to the "True" value isn't included. The
example posted is an explicit comparison to the VB Constant True which
is defined as -1.

Gerald Hernandez

2005-08-30, 6:55 pm

"Duane Bozarth" <dpbozarth@swko.dot.net> wrote in message
news:43145E75.9A25FC2@swko.dot.net...
> Dave wrote:
treated[color=darkred]
>
> Only if the explicit comparison to the "True" value isn't included. The
> example posted is an explicit comparison to the VB Constant True which
> is defined as -1.

Correct, as this is an explicit comparison to True.
Note that in the other version without the explicit comparison, it compares
to False (0). So any non-zero value will fail the test / jump out.

We have to keep in mind that the compiled code is often-times implemented
differently than what we might expect from the VB source. In the event that
you are comparing an Integer value, I suspect that the compiler would
implement a test against 0 as opposed to directly against -1. Although this
is not something I have verified yet.

Gerald

Duane Bozarth

2005-08-30, 6:55 pm

Gerald Hernandez wrote:
....
> We have to keep in mind that the compiled code is often-times implemented
> differently than what we might expect from the VB source. In the event that
> you are comparing an Integer value, I suspect that the compiler would
> implement a test against 0 as opposed to directly against -1. Although this
> is not something I have verified yet.
>

I suspect if you did investigate you might also discover the optimizer
<might> choose a different branch instruction depending on the content
of the Else or other more in-depth nesting. I've never investigated the
VB compiler in depth to discover this, but it would not surprise me that
different choices could possibly be made by the optimizer.

Gerald Hernandez

2005-08-30, 6:55 pm

"Duane Bozarth" <dpbozarth@swko.dot.net> wrote in message
news:431470D5.D15FBB67@swko.dot.net...
> Gerald Hernandez wrote:
> ...
implemented[color=darkred]
that[color=darkred]
this[color=darkred]
>
> I suspect if you did investigate you might also discover the optimizer
> <might> choose a different branch instruction depending on the content
> of the Else or other more in-depth nesting. I've never investigated the
> VB compiler in depth to discover this, but it would not surprise me that
> different choices could possibly be made by the optimizer.

Yes indeed it very well might. In ASM, there are a number of flexible
choices. Jump if Equal, Jump if Not Equal, Jump if Greater than, Jump if
Less than, and more. For the most part the VB compiler does an excellent job
of choosing the most logical option. However, in a few cases it optimizes
too much or interprets your intentions incorrectly. Hence why I like to be
quite explicit :-)
While it may choose to implement it differently than I did, I am assured
that whatever it does will work correctly.

Gerald

Duane Bozarth

2005-08-30, 6:55 pm

Gerald Hernandez wrote:
>
....

> Less than, and more. For the most part the VB compiler does an excellent job
> of choosing the most logical option. However, in a few cases it optimizes
> too much or interprets your intentions incorrectly.

What conditions would those be? I've had the VB compiler fail to
generate code on occasion, but I personally have never found a case of
an actual compiler bug. That doesn't imply, of course, that there are
none, but the VB compiler is pretty robust ime.

> ...Hence why I like to be quite explicit :-)
> While it may choose to implement it differently than I did, I am assured
> that whatever it does will work correctly.

The point I tried to make way back was that

"If Variable Then" and "If Variable=True Then"

are not actually identical in that VB treats any nonzero value as True
and it is possible to load values of other than True and False into
Variable (and even into a Boolean if one works at it).

Gerald Hernandez

2005-08-30, 6:55 pm

"Duane Bozarth" <dpbozarth@swko.dot.net> wrote in message
news:431488D7.745223EF@swko.dot.net...
> Gerald Hernandez wrote:
> ...
>
job[color=darkred]
optimizes[color=darkred]
>
> What conditions would those be? I've had the VB compiler fail to
> generate code on occasion, but I personally have never found a case of
> an actual compiler bug. That doesn't imply, of course, that there are
> none, but the VB compiler is pretty robust ime.
>
>
> The point I tried to make way back was that
>
> "If Variable Then" and "If Variable=True Then"
>
> are not actually identical in that VB treats any nonzero value as True
> and it is possible to load values of other than True and False into
> Variable (and even into a Boolean if one works at it).

heh, well I'm actually agreeing with you I think.
AFA reproducable examples of where the compiler gets it wrong, by nature it
is inconsistent and I haven't found a particular scenario that is
"reproducible". In one compile it doesn't work. Make no changes and
re-compile and it works. I have been hit by this on a few, although rare,
occasions, and the point at which it appeared to be broken was in ambiguous
comparisons. Certainly, it could indicate some other issue, and I've had
those as well, but also rare.

Agreed that those comparisons are in fact implemented differently. However,
I believe that the compiler is robust enough that if you use values besides
True/False, it will choose an implementation that is appropriate.

All this has me thinking that maybe I should examine this more closely for
the sake of knowledge. When I get a chance I will do that and post my
results.

Gerald

Duane Bozarth

2005-08-30, 6:55 pm

Gerald Hernandez wrote:
....
> AFA reproducable examples of where the compiler gets it wrong, by nature it
> is inconsistent and I haven't found a particular scenario that is
> "reproducible". In one compile it doesn't work. Make no changes and
> re-compile and it works. I have been hit by this on a few, although rare,
> occasions, and the point at which it appeared to be broken was in ambiguous
> comparisons. Certainly, it could indicate some other issue, and I've had
> those as well, but also rare.

By "work" do you mean actually built demonstrably wrong executable code
or simply failed to build?

I've had the latter, but I don't recall ever seing the former.

> Agreed that those comparisons are in fact implemented differently. However,
> I believe that the compiler is robust enough that if you use values besides
> True/False, it will choose an implementation that is appropriate.

I don't know what the above means??? Can you give an example of what you
mean by "robust enough"?

Oh, btw, I think we are mostly in agreement altho as noted there are a
couple of details in what you've said that I don't fully follow you...

Karl E. Peterson

2005-08-30, 6:55 pm

Dave wrote:
>
> Are you sure about this?
> I don't think "cmp bResult, -1" would work as ANY non-zero value is
> treated as true.

My money's on "jnz", not "cmp"...
--
Working Without a .NET?
http://classicvb.org/petition

Sponsored Links