Как проверить, какая реализация метода работает быстрее

Question

Хотя вопрос проверьте, является ли ввод типом строки было закрыто. Два ответа вызвали у меня в голове вопрос о микрооптимизации:какое из двух приведенных ниже решений будет работать лучше?

Рид Копси предоставил решение с использованием Char.IsLetter:

string myString = "RandomStringOfLetters";
bool allLetters = myString.All( c => Char.IsLetter(c) );

Адаптированный решение с использованием регулярного выражения от Марк Байерс:

string s = "RandomStringOfLetters";
bool allLetters = Regex.IsMatch(s, "^[a-z]+$", RegexOptions.IgnoreCase);

Не желая просто задавать вопрос Риду или Марку, я решил написать быстрый тест, чтобы определить, кто работает лучше.Проблема в том, что я не особо оптимизировал код (я склонен ставить читаемость кода превыше всего).

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

Редактировать

я изменил Ответ Мартина работать с Console.WriteLine(...) и запустил его как консольное приложение.Не уверен, как именно Линкпад запускает приложения, но результаты были примерно такими же:

41
178

Answer 1

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

1. Всегда запускайте тест более 1 раза.При первом запуске JIT потребует дополнительных затрат, а время может ввести в заблуждение.Хорошим подходом будет прогон много раз и получение среднего значения (например, я часто запускаю такой тест 100 000 раз).
2. Всегда запускайте тест с полной сборкой выпуска вне процесса размещения Visual Studio.(По умолчанию для этого можно использовать сочетание клавиш Ctrl+F5.) Хост Visual Studio существенно влияет на время.

Answer 2

тебе следует проверить System.Diagnostics.Stopwatch!

http://msdn.microsoft.com/en-us/library/system.diagnostics.stopwatch.aspx

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

Надеюсь, это поможет.

Answer 3

Я просто соединил это в LINQPad в качестве примера того, как я бы это сделал (отсюда и вызовы Dump() — Замените на Console.WriteLine(...), если вы не используете этот удобный инструмент).

Похоже, что способ LINQ чуть более чем в четыре раза быстрее:

System.Diagnostics.Stopwatch stopwatch = new Stopwatch();

stopwatch.Start();
for (int i = 0; i < 100000; i++)
{
 string myString = "RandomStringOfLetters";
 bool allLetters = myString.All( c => Char.IsLetter(c) );
}
stopwatch.Stop();
stopwatch.ElapsedMilliseconds.Dump();

stopwatch.Reset();

stopwatch.Start();
for (int i = 0; i < 100000; i++)
{
 string s = "RandomStringOfLetters";
 bool allLetters = Regex.IsMatch(s, "^[a-z]+$", RegexOptions.IgnoreCase);
}
stopwatch.Stop();
stopwatch.ElapsedMilliseconds.Dump();

Выход:

47 
196

Answer 4

Существует класс System.Diagnostics.Stopwatch, который можно использовать.

Какой бы код вы ни тестировали, запустите тест один раз, чтобы исключить затраты JIT, а затем запустите его еще раз для определения окончательного времени.Большинство отдельных показателей времени могут быть нерепрезентативными из-за других факторов на ПК, поэтому выполните множество итераций, а затем рассчитайте на их основе среднее время выполнения.

Answer 5

Используйте класс System.Diagnostics.Stopwatch.

Запустите StopWatch и выполните несколько тысяч итераций, остановите его и проверьте общее количество прошедших миллисекунд.

Answer 6

Шаги, чтобы определить, что быстрее: -

1. Соберите коллекцию компьютеров, достаточно пары сотен, AMD/Intel/другие, 32-битные/64-битные,...

2. Установите каждую интересующую вас платформу .NET на каждую из них (по очереди).

3. Попробуйте каждую комбинацию вариантов оптимизации для компиляции (по очереди)

4. Используйте StopWatch для тестирования большого прогона каждого

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

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