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

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

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

Вывод из тестовой среды Ааронотса

Short Loop: Elapsed Time = 00:00:00.8299340
Byte Loop: Elapsed Time = 00:00:00.8398556
Int Loop: Elapsed Time = 00:00:00.3217386
Long Loop: Elapsed Time = 00:00:00.7816368

int намного быстрее

Вывод от Джона

ByteLoop: 1126ms
ShortLoop: 1115ms
IntLoop: 1096ms
BackToBack: 3283ms
DelegateOverhead: 0ms

ничего в нем

Джон имеет большую фиксированную константу вызова tostring в результатах, которая может скрывать возможные преимущества это могло бы произойти, если бы работа, выполняемая в цикле, была меньше. Aaronaught использует 32-битную ОС, которая, похоже, не получит такой же выгоды от использования int, как установка x64, которую я использую.

Аппаратное / программное обеспечение Результаты были получены на процессоре Core i7 975 с тактовой частотой 3,33 ГГц с отключенным турбо-режимом и привязкой к ядрам, настроенной для уменьшения влияния других задач. Все настройки производительности установлены на максимум, а антивирусные программы / ненужные фоновые задачи приостановлены. Windows 7 x64 ultimate с 11 ГБ свободной оперативной памяти и очень низкой активностью ввода-вывода. Запуск в конфигурации выпуска, встроенной в vs 2008, без подключенного отладчика или профилировщика.

Повторяемость Первоначально повторяется 10 раз, изменяя порядок выполнения для каждого теста. Вариации были незначительны, поэтому я опубликовал только свой первый результат.При максимальной загрузке процессора соотношение времени выполнения оставалось неизменным. Повторные прогоны на нескольких блейд-серверах x64 xp xeon дают примерно одинаковые результаты с учетом поколения ЦП и ГГц

Профилирование Профилировщик Redgate / Jetbrains / Slimtune / CLR и мой собственный профилировщик все показывают, что результаты верный.

Сборка отладки Использование настроек отладки в VS дает стабильные результаты, такие как у Aaronaught.

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

Предложения: битовые сдвиги, умножение, манипуляции с массивами, сложение и многое другое ...

Большая часть этого времени, вероятно, тратится на запись в консоль. Попробуйте сделать что-нибудь кроме этого в цикле ...

Дополнительно:

• Использование DateTime.Now - плохой способ измерения времени. Используйте System.Diagnostics.Stopwatch вместо
• После того, как вы избавитесь от консоли .WriteLine , цикл из 127 итераций будет слишком коротким для измерения. Вам нужно запустить цикл много раз, чтобы получить разумное измерение.

Вот мой тест:

using System;
using System.Diagnostics;

public static class Test
{    
    const int Iterations = 100000;

    static void Main(string[] args)
    {
        Measure(ByteLoop);
        Measure(ShortLoop);
        Measure(IntLoop);
        Measure(BackToBack);
        Measure(DelegateOverhead);
    }

    static void Measure(Action action)
    {
        GC.Collect();
        GC.WaitForPendingFinalizers();
        GC.Collect();
        Stopwatch sw = Stopwatch.StartNew();
        for (int i = 0; i < Iterations; i++)
        {
            action();
        }
        sw.Stop();
        Console.WriteLine("{0}: {1}ms", action.Method.Name,
                          sw.ElapsedMilliseconds);
    }

    static void ByteLoop()
    {
        for (byte index = 0; index < 127; index++)
        {
            index.ToString();
        }
    }

    static void ShortLoop()
    {
        for (short index = 0; index < 127; index++)
        {
            index.ToString();
        }
    }

    static void IntLoop()
    {
        for (int index = 0; index < 127; index++)
        {
            index.ToString();
        }
    }

    static void BackToBack()
    {
        for (byte index = 0; index < 127; index++)
        {
            index.ToString();
        }
        for (short index = 0; index < 127; index++)
        {
            index.ToString();
        }
        for (int index = 0; index < 127; index++)
        {
            index.ToString();
        }
    }

    static void DelegateOverhead()
    {
        // Nothing. Let's see how much
        // overhead there is just for calling
        // this repeatedly...
    }
}

И результаты:

ByteLoop: 6585ms
ShortLoop: 6342ms
IntLoop: 6404ms
BackToBack: 19757ms
DelegateOverhead: 1ms

(Это на нетбуке - отрегулируйте количество итераций, пока не получите что-то разумное :)

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