Действительно ли работает функция ProfileOptimization?

Одним из новых улучшений производительности для .NET 4.5 является внедрение "MultiCode JIT".

Подробнее см. здесь.

Я пробовал это, но, похоже, это не влияет на мое приложение.

Причина, по которой меня интересует, заключается в том, что мое приложение (IronScheme) занимает много времени для запуска, если не NGEN'd, что подразумевает, что при запуске задействовано значительное количество JIT'ng. (1,4 сек против 0,1 с при NGEN'd).

Я выполнил инструкции по включению этого, и я вижу, что создается "маленький" (4-12 КБ). Но при последующем запуске он, похоже, абсолютно не влияет на улучшение времени запуска. Это еще 1,4 секунды.

Кто-нибудь действительно видел (или делал) эту работу на практике?

Кроме того, существуют ли какие-либо ограничения на то, какой код будет "отслеживаться"? Например: контексты загрузки сборок, переходные сборки и т.д. Я спрашиваю об этом, поскольку созданный файл никогда не растет, но я на самом деле генерирую достаточное количество кода (в переходной сборке).

Одна ошибка, с которой я столкнулся, заключалась в том, что SetProfileRoot, похоже, не понимает a/как разделитель путей, обязательно используйте \.

Ответы

Ответ 1

Эмпирическое правило, которое мы используем в Microsoft, заключается в том, что Multicore JIT дает вам примерно половину пути к производительности запуска NGEN. Таким образом, если ваше приложение начнет через 0,1 секунды с NGEN и 1,4 секунды без NGEN, мы ожидаем, что запуск Multicore JIT займет около 0,75 секунды.

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

Если вы хотите узнать, что происходит в вашем случае, у нас есть инструментарий ETW (Event Tracing For Windows) функции MCJ, и мы скоро выпустим версию PerfView, которая сможет собирать эти события, если вы проследите за запуском вашего приложения.

Обновление: PerfView был обновлен, чтобы отображать информацию о JIT в фоновом режиме. Ниже приведены шаги по диагностике с последней версией (1.2.2.0):

  • Соберите трассировку, используя PerfView для запуска вашего приложения, используя команду "Сбор" > "Выполнить" или "Сбор" > "Собрать" в главном меню PerfView.
  • Предполагая, что вы использовали Collect- > Run, поместите имя своего .exe в текстовое поле Command, выберите имя файла (например, IronScheme.etl), выберите "Фон JIT" из "Дополнительные параметры" и нажмите "Запустить команду".
  • Закройте приложение и дважды щелкните файл IronScheme.etl, который будет сгенерирован.
  • Дважды щелкните по представлению JIT Stats в списке под IronScheme.etl, вы увидите что-то вроде этого в появившемся представлении:
This process uses Background JIT compilation (System.Runtime.ProfileOptimize) 
    Methods Background JITTed : 2,951 
    Percent # Methods Background JITTed : 52.9% 
    MSec Background JITTing : 3,901 
    Percent Time JITTing is Background : 50.9% 
    Background JIT Thread : 11308

Вы можете щелкнуть "Просмотр исходных данных Jit Diagnostics", чтобы просмотреть все события MCJ в excel. Один вопрос, который я забыл спросить: запускаете ли вы это на многоядерной машине или многоядерной VM? Общей ошибкой является проверка MCJ в виртуальной машине, которая имеет только один логический процессор.

Ответ 2

Вызов Activator.CreateInstance во время запуска, похоже, убивает MCJ?

Или, скорее, это вызвало решение Ассамблеи, которое, похоже, прекратило MCJ. И никогда не работать после этого. Возможно, документы MSDN должны упоминать об этом.