Processing If vs Select

[Sorwen]

Ok, keep in mind that my Programming Class was 12 years ago. So this question may be a totally moot point now. In C++ If Statements took less time to process than Switch Statements. My question is in VB do If Statements take less time to process than Select Statements or is it a moot point? I'm not talking the difference in rather small statements, but large ones.

Side question, for bonus points , does it even matter in C++ any more?

 

[MajP]

Do not know about the differences between the constructs, but there is a lot of fine tuning within the constructs that can be done. A lot of it is counter intuitive.

Example. Split the boolean checks to short circuit

Private Sub Command1_Click()
' Slow code checks f2 even if f1 is false
If f1 And f2 Then
Debug.Print "True"
End If

' Faster because f2 not executed when f1 is false
If f1 Then
If f2 Then
Debug.Print "True"
End If
End If
End Sub

Different functions have different speeds
<> is faster than either the >,<

Do not use "iif". NEVER NEST "iif". Reallll slow

Design you checks with the most likely cases first (if you know)

Use multiple lines for If then.
If .... then
do somethin
end if
not
if Then do something

 

[Sorwen]

Thanks for the input. I've seen iif when using excel, but I've never tried using it. I do use if Then do something some times often. Good to know I shouldn't. Thanks.

 

[avolkert]

Wow, Kuddo's to MajP ! ;-)

Aside from the technical aspects of speed (measured in nano-seconds) ... let's not overly confuse the issue here. Efficiency is all about OVERALL Efficiency.

Example: How many times have we all had to adjust or modify someone else's code or even our own after 3-6+ months after we rolled it out ? We end up spending hours trying to figure it out.

Rather than If this then this, or If this but not that uless this and the other thing are there ... a simple select statement can be very powerful.

They can also be far easier to read ... consider creating a temporary data mining string before a select.

Example:

if A < 0 then DM_STR = "-"
else if A = 0 then DM_STR = "0"
else DM_STR = "+"

if B < 0 then DM_STR = DM_STR & "-"
else if B = 0 then DM_STR = DM_STR & "0"
else DM_STR = DM_STR & "+"

select DM_STR
case "--"
' Both are neg
case "-0"
' A is neg, B is zero
case ...

end select

Lots of code, but for situations with messy data, it can be far easier to keep track of downstream.

For really messy situations where there are plethoras of nested IF statements, a simple temporary data mining string and a clear select statement can make all of the difference in the world.

Again, Kudo's to MajP ... that was a great answer.

Alan J. Volkert
Fleet Services
GE Commercial Finance Capital Solutions
(World's longest company title)
Eden Prairie, MN

 

[Golom]

Over in one of the VB forums a few months ago someone posted some code to test "Select" Vs. "If" statement speed. It turned out that a "Select ... Case" ran about twice as fast as the corresponding "If .. Then .. Else" construct. That sounds like a lot but (if I recall correctly) the select took about 10 seconds to execute a million passes through it while the "If" was about 20 seconds on my machine (P4-2.8GHz; 1GB Ram). We are therefore dealing with times on the order of 10[sup]-5[/sup] seconds per iteration so clarity is probably much more relevant than speed.

[small]No! No! You're not thinking ... you're only being logical.
- Neils Bohr[/small]

 

[JoeAtWork]

I agree with Golom, the choice is generally based on what makes most sense. For checking one or two conditions, "If" tends to make sense. For testing 3 or more possible values in a variable, the choice would tend to be SELECT.

I suppose if it was inside something that might loop a million times, than you might choose SELECT no matter what. But I can't think of any code I've written where that would happen.