Тестирование вашего кода на скорость? - PullRequest
8 голосов
/ 23 сентября 2008

Я новичок, но я писал небольшую программу, которая работала со строками в C #, и я заметил, что если я делаю несколько вещей по-другому, код выполняется значительно быстрее.

Так что меня удивило, как вы справляетесь со скоростью выполнения вашего кода? Есть ли (бесплатные) утилиты? Пойдете ли вы по-старому с System.Timer и сделаете это сами?

Ответы [ 9 ]

14 голосов
/ 23 сентября 2008

То, что вы описываете, называется профилированием производительности. Есть много программ, которые вы можете сделать для этого, например Jetbrains profiler или Ants profiler , хотя большинство из них замедляют работу вашего приложения в процессе измерения его производительности.

Чтобы выполнить собственное профилирование производительности вручную, вы можете использовать System.Diagnostics.Stopwatch и простую Console.WriteLine, как вы описали.

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

11 голосов
/ 23 сентября 2008

ANTS Profiler от RedGate - действительно хороший профилировщик производительности. dotTrace Profiler от JetBrains тоже отлично. Эти инструменты позволят вам увидеть показатели производительности, которые можно детализировать по каждой отдельной строке.

Scree shot ANTS Profiler: ANTS http://www.red -gate.com / products / ants_profiler / images / app / timeline_calltree3.gif

Если вы хотите убедиться, что определенный метод остается в пределах определенного порога производительности во время модульного тестирования, я бы использовал Stopwatch класс , чтобы контролировать время выполнения метода один или много раз Зациклите и вычислите среднее значение, а затем Assert против результата.

7 голосов
/ 23 сентября 2008

Просто напоминание - обязательно скомпилируйте в Relase, а не в Debug! (Я видел эту ошибку, сделанную опытными разработчиками - ее легко забыть).

3 голосов
/ 23 сентября 2008

Что вы описываете, это «Настройка производительности». Когда мы говорим о настройке производительности, есть два угла к этому. (a) Время ответа - сколько времени занимает выполнение конкретного запроса / программы. (b) Пропускная способность - сколько запросов он может выполнить за секунду. Когда мы обычно «оптимизируем» - когда мы исключаем ненужную обработку, улучшается как время отклика, так и пропускная способность. Однако, если у вас есть события ожидания в вашем коде (например, Thread.sleep (), ожидание ввода-вывода и т. Д.), На ваше время отклика влияют, но на пропускную способность не влияют. Принимая параллельную обработку (порождая несколько потоков), мы можем улучшить время отклика, но пропускная способность не улучшится. Обычно для серверного приложения важны время отклика и пропускная способность. Для настольных приложений (таких как IDE) пропускная способность не важна, важно только время отклика.

Вы можете измерить время отклика с помощью «Тестирования производительности» - вы просто записываете время отклика для всех ключевых транзакций. Вы можете измерить пропускную способность с помощью «нагрузочного тестирования» - вам нужно непрерывно накачивать запросы от достаточно большого количества потоков / клиентов, чтобы загрузка ЦП серверного компьютера составляла 80-90%. Когда мы прокачиваем запрос, нам нужно поддерживать соотношение между различными транзакциями (так называемая комбинация транзакций) - например, в системе резервирования будет 10 бронирований на каждые 100 поисковых запросов. на каждые 10 бронирований и т. д. будет одна отмена.

После определения транзакций, требующих настройки времени отклика (тестирование производительности), вы можете определить горячие точки с помощью профилировщика. Вы можете определить «горячие точки» для пропускной способности, сравнив долю времени отклика этой транзакции. Предположим, в поиске, бронировании, отмене сценария соотношение составляет 89: 10: 1. Время отклика составляет 0,1 с, 10 с и 15 с. нагрузка для поиска - 0,1 * .89 = 0,089 нагрузка для бронирования - 10 * .1 = 1 нагрузка для cancell = 15 * .01 = 0,15 Здесь настройка бронирования даст максимальное влияние на пропускную способность. Вы также можете определить «горячие точки» для пропускной способности, многократно получая дампы потоков (в случае приложений на основе Java).

1 голос
/ 23 сентября 2008

Используйте профилировщик.

Если вам нужно выбрать только один конкретный метод, класс Секундомер может быть хорошим выбором.

0 голосов
/ 22 февраля 2016

Это простой пример для проверки скорости кода. Я надеюсь, что помог тебе

class Program {
    static void Main(string[] args) {
        const int steps = 10000;
        Stopwatch sw = new Stopwatch();

        ArrayList list1 = new ArrayList();
        sw.Start();
        for(int i = 0; i < steps; i++) {
            list1.Add(i);
        }
        sw.Stop();
        Console.WriteLine("ArrayList:\tMilliseconds = {0},\tTicks = {1}", sw.ElapsedMilliseconds, sw.ElapsedTicks);

        MyList list2 = new MyList();
        sw.Start();
        for(int i = 0; i < steps; i++) {
            list2.Add(i);
        }
        sw.Stop();
        Console.WriteLine("MyList:  \tMilliseconds = {0},\tTicks = {1}", sw.ElapsedMilliseconds, sw.ElapsedTicks);
0 голосов
/ 20 ноября 2008

Существует встроенная опция .NET (Team Edition для разработчиков программного обеспечения), которая может удовлетворить некоторые потребности анализа производительности. В меню 2005.NET IDE выберите Инструменты-> Инструменты производительности-> Мастер производительности ...

[GSS, вероятно, правильно, что вы должны иметь Team Edition]

0 голосов
/ 23 сентября 2008

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

0 голосов
/ 23 сентября 2008

Я делаю следующие вещи: 1) Я использую тики (например, в VB.Net Now.ticks) для измерения текущего времени. Я вычитаю начальные тики из значения готовых тиков и делю на TimeSpan.TicksPerSecond, чтобы узнать, сколько секунд это заняло. 2) Я избегаю операций пользовательского интерфейса (например, console.writeline). 3) Я запускаю код по существу цикла (например, 100 000 итераций), чтобы как можно лучше выделить переменные использования / ОС.

...