Какой метод будет работать лучше? (Или не достаточно разницы, чтобы иметь значение?) - PullRequest
Новая
       10

Какой метод будет работать лучше? (Или не достаточно разницы, чтобы иметь значение?)

3 голосов
/ 04 февраля 2010

Что (если таковое имеется) из следующего даст наименьший удар по производительности? Или разница настолько мала, что я должен использовать наиболее читабельный?

На той же странице я отметил 3 стиля, использовавшихся предыдущими сопровождающими:

Метод 1 : 

If (strRqMethod = "Forum" or strRqMethod = "URL" or strRqMethod = "EditURL" or strRqMethod = "EditForum") Then
 ...
End If

Метод 2 : 

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

Метод 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

Отключение от классического ASP / VBScript не вариант, поэтому эти комментарии не нужно публиковать.

Ответы [ 4 ]

4 голосов
/ 04 февраля 2010

Вы можете сделать это самостоятельно, чтобы получить наилучшие результаты, так как некоторые характеристики будут различаться в зависимости от размера входной строки.

Тем не менее, я скажу, что с точки зрения обслуживания, второй немного легче читать / понимать.

2 голосов
/ 04 февраля 2010

Ну, метод 3 явно будет работать хуже, чем два других.

Между методом 1 и методом 2 разница будет незначительной. Стоит помнить, что VBScript не выполняет сокращение булевых выражений, поэтому в методе 1 strRqMethod будут сравниваться все строки, даже если он соответствует первой. Оператор Case в методе 2 как минимум имеет возможность не делать этого и, скорее всего, прекратит сравнение, когда будет найдено первое совпадение в наборе.

В конце концов, я бы выбрал метод 2 , а не , потому что я думаю, что может быть быстрее, а потому, что он выражает намерение кода самым ясным образом.

1 голос
/ 04 февраля 2010

Образованное предположение:
Что касается производительности, первые два подхода примерно эквивалентны; Третий метод, скорее всего, медленнее, даже если он встроен.

Кроме того, разница между первыми двумя значениями, вероятно, находится в диапазоне микросекунд, поэтому вы можете смело считать, что это случай с костью преждевременная оптимизация ...

Поскольку мы говорим о логической оценке OR-ed, необходимо кое-что знать:

  • Большинство компиляторов / интерпретаторов будут оценивать логические выражения с « оптимизация короткого замыкания », что означает, что при первом найденном истинном условии, последующие условия ИЛИ НЕ оцениваются ( так как они не изменили бы результат). Поэтому хорошей идеей будет перечислить условие в [грубом] порядке убывания вероятности, то есть сначала перечислить все общие случаи. (Также обратите внимание, что оценка короткого замыкания также используется с выражениями AND-ed, но, конечно, в обратном порядке, т. Е. При первом ложном условии, оценка останавливается, поэтому предлагается записать выражение с наиболее вероятными условиями , чтобы не выполнить первый).
  • Сравнение строк является настолько распространенной задачей, что большинство языков делают это очень оптимизированным способом, на очень низком уровне языка. Большинство хитростей, которые мы можем решить для улучшения этой конкретной задачи, обычно менее эффективны, чем собственный оператор.
0 голосов
/ 04 февраля 2010

До тех пор, пока это не будет выполнено 100 000 (другими словами, несколько раз) в цикле, это не имеет значения. Хотя это анализируемый код, мы все же можем предположить, что синтаксический анализ выполняется быстро и достаточно быстро, чтобы не иметь значения.

Я обнаружил серьезные проблемы с производительностью, только когда вы объединяете много строк - как я однажды обнаружил при запуске страницы, добавляя код отладки в глобальную строку, чтобы иметь возможность отображать отладку только в нижней части страницы. Чем длиннее страница, тем больше кода она выполняла, тем больше кода отладки я добавила, и тем больше времени потребовалось для отображения страницы. Поскольку эта страница осуществляла некоторый доступ к базе данных, я предположил, что где-то в этом коде произошла задержка, только чтобы выяснить, что это были просто операторы отладки (если честно, у меня был объединен журнал строки отладки). *

...