Which method will perform better? (Or is there not enough of a difference to matter?)

Which (if any) of the following will give the smallest performance hit? Or is the difference so small that I should use the most readable?

In the same page I've noted 3 styles used by previous maintainers:

Method 1:

If (strRqMethod = "Forum" or strRqMethod = "URL" or strRqMethod = "EditURL" or strRqMethod = "EditForum") Then
 ...
End If
开发者_如何学运维

Method 2:

Select Case strRqMethod
 Case "Reply", "ReplyQuote", "TopicQuote"
  'This is the only case in this statement...'
  ...
End Select

Method 3:

If InArray("Edit,EditTopic,Reply,ReplyQuote,Topic,TopicQuote",strRqMethod) Then
 ...
End If

.
.
.

'Elsewhere in the code'
function InArray(strArray,strValue)
 if strArray <> "" and strArray <> "0" then
  if (instr("," & strArray & "," ,"," & strValue & ",") > 0) then
   InArray = True
  else
   InArray = False
  end if
 else
  InArray = False
 end if
end function

Moving away from Classic ASP/VBScript is not an option, so those comments need not bother to post.

---

You can benchmark this yourself to get the best results, as some performance will differ depending on the size of the input string.

However, I will say from a maintenance perspective, the second one is a bit easier to read/understand.

---

Well Method 3 is clearly going to perform worse than the other two.

Between Method 1 and Method 2 the difference is going to be marginal. Its worth remembering that VBScript doesn't do boolean expression short cutting hence in Method 1 strRqMethod will be compared with all strings even if it matches the first one. The Case statement in Method 2 at least has the option not to do that and likely will stop comparing when the first match is found in the set.

Utimately I would choose Method 2 not because I think it might be faster but because it expresses the intent of the code in the clearest way.

---

Educated guess:
Performance-wise, first two approaches are roughly equivalent; third method is very likely slower, even if it gets inlined.

Furthermore the differential between the first two are likely in the micro-seconds range, so you can safely consider this to be a bone fide case of premature optimization...

Since we're on the topic of OR-ed boolean evaluation, a few things to know:

• Most compilers/interpreters will evaluate boolean expressions with "short circuit optimization", which means that at the first true condition found, the subsequent OR-ed conditions are NOT evaluated (since they wouldn't change the outcome). It is therefore a good idea to list the condition in [rough] decreasing order of probability, i.e. listing all the common cases first. (Also note that short circuit evaluation is also used with AND-ed expressions, but of course in the reverse, i.e. at the first false condition, the evalation stops, hence suggesting to write the expression with the most likely conditions to fail first).
• Comparing strings is such a common task that most languages have this done in a very optimized fashion, at a very low level of the language. Most any trick we can think to improve this particular task is typically less efficient than the native operator.

---

As long as this is not done 100.000 (in other words: a lof of) times in a loop, it makes no difference. Although it is parsed code, we may still assume that the parsing is done swift and quickly enough not to make a difference.

I found severe performance problems only when you are concatenating a lot of strings - like I once found out when running a page, adding debug code to a global string to be able to dispay the debug only at the bottom of the page. The longer the page was, the more code it ran, the more debug code I added, and the longer the time it took to display the page. Since this page was doing some database access, I presumed it was somewhere in that code that the delay occured, only to found out that it was just the debug statements (to be honest, I had a log of debug string concatenated).