Потенциальные проблемы при использовании ProfileOptimization в разных версиях

Question

В попытке улучшить производительность запуска моей программы при запуске я называю:

ProfileOptimization.SetProfileRoot(path); 
ProfileOptimization.StartProfile("profile"); 

У меня есть несколько вопросов:

Могу ли я использовать один и тот же профиль ProfileOptimization по версии моей программы? Что произойдет, если методы были изменены или удалены?

Что произойдет, если я использую один профиль, но запускаю свою программу несколько раз?

Answer 1

PerfView документация состояния следующие:

Фон JIT имеет следующие характеристики

1. Это не работает на самом первом запуске на данной машине. Нет профиля и, следовательно, нечего действовать как «оракул», который указывает, что компилировать.
2. Это не работает, если то, что произошло на предыдущих запусках, является хорошим показателем того, что произойдет на этот раз. Например, если какая-то конкретная программа обычно вызывается с аргументами командной строки, которые делают ее очень разные вещи при каждом запуске, тогда фоновый JIT не будет работать хорошо для случая запуска.
3. Это самовосстановление, однако. Например, если программа часто используется с одним набором аргументов командной строки, но иногда используется с другим, что приводит к тому, что она запускает очень разные кодовые пути, то она будет хорошо работать для большинства запусков (но не необычная команда, а другая после этого).
4. Вы можете устранить проблему, описанную выше, путем введения большего количества профилей для одного и того же приложения. Если у вас есть профиль не в режиме START, а в начале каждой команды, время выполнения будет содержать профиль для каждой команды, и каждый из них будет работать хорошо.
5. Фоновая компиляция JIT имеет тенденцию только нажимать около 1/2 времени JIT сценария на фон, где он не влияет на время от конца до конца. Это связано с тем, что часто «основной поток» может «догнать» фоновый поток и использовать метод до того, как фоновый поток завершит его компиляцию. В типичном случае, когда стоимость ЦП, связанная с компиляцией JIT, намного больше, чем выполнение кода JITTed, это приводит к получению половины методов, скомпилированных основным потоком и половиной, скомпилированной фоновым потоком. Это то, что NGENing лучше, чем исходная компиляция JIT.

Что может пойти не так с фоновой JIT-компиляцией.

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

1. При загрузке модулей может быть вызван конструктор модуля, который может иметь побочные эффекты (даже это очень редко). Таким образом, если фоновый JITTing приведет к загрузке модуля раньше, чем в противном случае, он может выявить (редкие) ошибки.Поскольку у фона JIT была очень высокая панель совместимости, он защищает от этого, группируя каждый метод с модулями EXACT, которые были загружены во время компиляции JIT, и только позволяет им быть фоновым JIT, скомпилированным после того, как все эти EXACT-модули также были загружены в текущий прогон. Таким образом, если у вас есть сценарий (скажем, открытие меню), где иногда загружается больше или меньше модулей (поскольку предыдущие действия пользователя приводили к загрузке различных модулей), тогда фоновый JIT может работать неправильно.
2. Если вы подключили обратный вызов события System.Assembly.ModuleResolve, возможно (хотя крайне маловероятный и очень плохой дизайн), что фоновый JITing может иметь побочные эффекты, если обратный вызов ModuleResolve возвращал разные ответы во втором прогоне, чем он сделал на первом запуске. Из-за этого фона компиляция JIT приостанавливается при первом вызове обратного вызова ModuleResolve.
3. Поскольку любой поиск модуля не выполняется, вызывается событие ModuleResolve, прежде чем он, наконец, завершится неудачей, это означает, что любое пробное тестирование для модулей, которые выходят из строя, также блокирует компиляцию фона JIT.

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