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).