What are differences between Portable and win-x64 when deploying?

Viewed 14268

I deploy my code to IIS on Windows Server 2016 and I am trying to understand the effective difference between selecting Portable vs win-x64 in the Publish/Settings/Target Runtime dropdown.

Will the site take longer to start under Portable because the JIT needs to compile the code to the specific architecture? Is there anything else?

enter image description here

3 Answers

Edit - Short Answer

If you choose portable, every time the app starts up it will need to go through JIT compilation on the parts of the application that actually execute. If your application is large, the performance can be impacted.

If you choose x64, the application will not slow down from compilation, because that is already done by the publish process on the build machine (your laptop).


Original Answer

When you choose the Portable publish option, you'll get a package that is capable of running on either x86 (32-bit) machines and x64 (64-bit) machines. With the portable option selected, on application launch you'll get JIT compiled code for the target machine (either x64 or x86) as the application stays running. However, if the application closes, all the code that was JIT compiled would be lost. The compiled code sits in memory until the application process ends. The next run would have to JIT compile the application again as it is used. The advantage here is that you'd only need to distribute one package, and it'll run on both x86/x64 machines.

The alternative is generating multiple packages, one for each target platform you intend to distribute your application on though. In this case, you'll get machine-specific packages that are already compiled, and do not require recompilation even after the application process ends and is restarted later. In this case your application will appear to run faster since the compilation is done once and only once, on the build server / machine. However it does impact your deployment style.

More information on .NET runtime identifiers can be found here: https://docs.microsoft.com/en-us/dotnet/core/rid-catalog

And a good document on JIT compiled code is here: https://www.telerik.com/blogs/understanding-net-just-in-time-compilation

The accepted answer is no longer true in Visual Studio 2022.

The obvious difference is that one is portable, whereas the other is for a specific architecture.

The not-so-obvious difference is that when you select win-x64, you are then given the option to "Enable ReadyToRun compilation".

However, ReadyToRun does not always mean faster. See the docs here for the nitty-gritty details.

In a nutshell, when ReadyToRun is selected, the compiler attempts to compile it as best as it can, but it doesn't have the specifics of the actual machine it will run on. As such, the file size is considerably larger as much as 2-3 times. The advice from the docs is to use it for large projects, and not for small projects, but you have to decide for yourself on the definition of large and small.

My advice would be to select the specific architecture if you know in advance what is is going to be. As for ReadyToRun, select it if testing shows it to be beneficial to startup time if that is important.

The accepted answer is kinda wrong about the JIT assumption (JIT compilation happens on the target machine regardless). The other answer from @Greg-Gum explains the R2R requirement but still does not explain what's happening under the hood.

When you set "Target Runtime" to "Portable" the publishing process includes runtime DLLs in the publish destination

There will be a /runtime subfolder in the publish destination, that will include native/runtime files and dependencies for multiple platforms and their combinations. This folder can be several megabytes.

EXAMPLE: let's say, your project uses SqlClient nuget. On Windows this nuget depends on sni.dll native library. So that file will be placed into /runtimes/win-x64/native/sni.dll and /runtimes/win-x86/native/sni.dll (corresponding versions)

That's just one example, there's many more stuff going on.

Related