Я развертываю свой код в IIS на Windows Server 2016 и пытаюсь понять эффективную разницу между выбором Portable и win-x64 в раскрывающемся списке Publish / Settings / Target Runtime.
Будет ли сайт дольше запускаться в Portable, потому что JIT необходимо скомпилировать код для конкретной архитектуры? Есть ли еще что-нибудь?





Изменить - короткий ответ
Если вы выберете portable, каждый раз, когда приложение запускается, ему необходимо будет проходить JIT-компиляцию в тех частях приложения, которые фактически выполняются. Если ваше приложение большое, это может повлиять на производительность.
Если вы выберете x64, приложение не будет замедляться при компиляции, потому что это уже сделано процессом публикации на машине сборки (вашем портативном компьютере).
Оригинальный ответ
Когда вы выбираете опцию публикации Portable, вы получаете пакет, который может работать как на x86 (32-битных) машинах, так и на x64 (64-битных) машинах. Если выбран вариант переносимости, при запуске приложения вы получите код, скомпилированный JIT для целевой машины (x64 или x86), поскольку приложение продолжает работать. Однако, если приложение закроется, весь код, который был скомпилирован JIT, будет потерян. Скомпилированный код остается в памяти до завершения процесса приложения. При следующем запуске приложение снова будет скомпилировано JIT по мере его использования. Преимущество здесь в том, что вам нужно будет распространить только один пакет, и он будет работать на обеих машинах x86 / x64.
Альтернативой является создание нескольких пакетов, по одному для каждой целевой платформы, на которой вы собираетесь распространять свое приложение. В этом случае вы получите машинно-зависимые пакеты, которые уже скомпилированы и не требуют перекомпиляции даже после завершения процесса приложения и его перезапуска позже. В этом случае ваше приложение будет работать быстрее, поскольку компиляция выполняется один раз и только один раз на сервере / машине сборки. Однако это влияет на ваш стиль развертывания.
Более подробную информацию об идентификаторах среды выполнения .NET можно найти здесь: https://docs.microsoft.com/en-us/dotnet/core/rid-catalog
И хороший документ по JIT-скомпилированному коду находится здесь: https://www.telerik.com/blogs/understanding-net-just-in-time-compilation
Теперь есть добавленная опция флажка «Включить компиляцию ReadyToRun» и, кажется, больше о том, о чем этот ответ. И этот доступен только для целей, зависящих от платформы. Когда он не отмечен, я не уверен, какая разница между целями.
Принятый ответ больше не соответствует действительности в Visual Studio 2022.
Очевидная разница в том, что один переносимый, а другой - для конкретной архитектуры.
Не столь очевидная разница в том, что при выборе win-x64 вам предоставляется возможность «Включить компиляцию ReadyToRun».
Однако ReadyToRun не всегда означает быстрее. См. Документацию здесь для более подробной информации.
Вкратце, когда выбран ReadyToRun, компилятор пытается скомпилировать его как можно лучше, но у него нет специфики реальной машины, на которой он будет работать. Таким образом, размер файла значительно больше, в 2-3 раза. Совет из документации - использовать его для больших проектов, а не для маленьких, но вы должны сами решить, какое определение у вас есть: большие и маленькие.
Я бы посоветовал выбрать конкретную архитектуру, если вы заранее знаете, какой она будет. Что касается ReadyToRun, выберите его, если тестирование показывает, что это полезно для времени запуска, если это важно.
Я сомневаюсь. Даже если вы используете
win-x64, JIT-компиляция все равно должна быть частью выполнения. .NET Native пока не применяется к .NET Core, поэтому нет AOT для замены JIT.