The quickest of two "If"s

Getting Started
1

In my programme the user inputs co-ordinates that are then stored in string properties. If a co-ordinate is missing a “B” for blank is stored.

Next I have to process them, first checking for blanks (“B”). I have found two ways.

Way1
If Xstart<>“B” And Xend<>“B” And Ystart<>“B” And Yend<>“B” Then…

Way 2
If InStr(Xstart+Ystart+Xend+Yend,“B”)=0 Then…

Which one run the quickest?

2

First, why not just leave the blank version blank instead of using “B”? And why are they strings instead of integers or doubles?

My guess is that the first version is faster, but that should be easy enough for you to test.

Also, you might want to create a class for your coordinates just to encapsulate them.

3

Way 1.
Was 2 does make three concat operations which allocate three temp strings just for that comparison.

4

This is a very small part of a very big programme. I’m using string arrays to store lots of info. “B” is used as a space filler. I’m also using “C” as a prefix for calculated values.

BUT…

I have just tested it. Wrote a little prog. Set “Profile Code” on.

Way 1 takes 2 milliseconds, way 2 takes 1 milliseconds. So logic is slower than concat ops.

5

2 milliseconds? I presume this is a measurement error…

6

Redid prog a few more times, trying methods in different orders. Profile Code not too accurate. Maybe methods too small.

7

You need to test in a large loop, same iterations for each, with #pragma BackgroundTasks = false in a compiled app.

8

The conclusion is way 2 is only quicker to type.

9

You can also do SELECT CASE in this case:

Select Case "B"
Case Xstart, Xend, Ystart, Yend
  // Do nothing
Else
  // No B's
End
10

I wouldn’t worry about the If, so much as the String comparison operation as being slow.

Are case sensitivity and unicode important?

  if X = "B"

will do a unicode-savvy case-insensitive comparison, which can be quite slow.

if StrComp(x,"B", 0)

will do a binary comparison which can be much, much faster.

11

But not for a single character comparison like this. The overhead of calling the method overwhelms the speed advantage of the byte comparison in my tests.

12

A test shows the opposite: Equals takes 156 msec, StrComp take 64 msec

13

I hate when other people test something and get the opposite results.

You tested in a compiled app?

14

I just ran the following test in a compiled app:

  #pragma BackgroundTasks False
  
  dim arr( 999999 ) as string
  
  for i as integer = 0 to arr.Ubound step 2
    arr( i ) = "B"
  next
  
  dim msg as string
  dim sw as new Stopwatch_MTC
  sw.Start
  
  for i as integer = 0 to arr.Ubound
    if arr( i ) = "B" then
      // Do something
    end if
  next
  
  sw.Stop

If I substitute the “=” with StrComp, it is slower by about 14%. Mind you, we are talking about 48 ms vs. 55 ms, so it no huge deal, but still slower.

15

In a compiled app the difference is more dramatic: 113msec vs 30msec.

Are you using the wrong StrComp mode?

My code:

Pushbutton1.action:
  #pragma DisableBackgroundTasks
  
  dim t0 as double = Microseconds
  dim X as string = "C"
  for i as integer = 1 to 1000000
    if X = "B" then
    end if
  next
  MsgBox "String equals took " + format((Microseconds-t0)/1000, "#") + "msec"

and

  #pragma DisableBackgroundTasks
  
  dim t0 as double = Microseconds
  dim X as string = "C"
  for i as integer = 1 to 1000000
    if strComp(X,"B",0) =0 then
    end if
  next
  MsgBox "StrComp binary took " + format((Microseconds-t0)/1000, "#") + "msec"
16

No, same.

What an odd difference in results. I’ll try your code in a little bit.

17

As an aside, Beware unnecessary code optimizations that obfuscate otherwise easy to read code. We’re quibbling about an IF condition? If you’ve optimized your code down to where this is your primary concern, my hat is off to you!

18

I get the same results. However, if I change the value of X to “B”, the “=” version takes half the time as StrComp, and that explains the discrepancy between my results and yours. My code was only matching half the time.

In fact, when there is a match, “=” takes about 7 ms and StrComp about 15 ms. With your code as written, it takes 170 ms vs. 28 ms. You’d think that StrComp, at least, would take the same amount of time whether there is a match or not.

How about that? :slight_smile:

So the bottom line is, if case matters, you’re better off using StrComp even for a small strings.

19

The thread topic has drifted (or perhaps “been hijacked”) where I’m focusing more on string comparison performance. I don’t think an almost 5-fold performance in string comparisons is something to ignore, at least not in those cases where the app is primarily doing string-based calculations.

20

But you’re comparing apples and oranges. By using mode 0 in strcomp, you’ve changed the sense of the comparison and are only handling non-UTF strings. Granted, that may make sense in many cases, but you have introduced a subtle difference and, depending on your goals, skewed the results.