I can’t measure a difference in startup time when using self-contained vs external runtimes. I haven’t looked at memory too much, but I use external runtimes all the time during development and there’s no significant difference on my machine either.
I did consider whether to use a self-contained build vs an external build. In the end I went with the self-contained for several reasons:
- Runtime version: If the user provides the .NET Core runtime, we have not much control over the version in use. That increases the number of potential bugs, and it’s super difficult to test with all different patch levels that the Core runtime has.
- Modern .NET Core doesn’t exactly have a super long lifetime. We will need to move to the next .NET LTS soon-ish, and unfortunately Microsoft doesn’t uninstall old runtimes due to backwards compatibility. I myself have all .NET Core runtimes all the way back to Core 5 on a recent machine, because programs install them and then never clean them up. You inevitably end up trashing the user’s system with old runtimes this way (and the user has no idea if they can safely remove them or not, nor do we)
- Security updates managed by us: This is both a pro and a con. The core runtimes receive regular security updates, and by pushing builds with the latest runtime we ensure that the user has these patches. Of course that also means that we need to do regular releases, otherwise the runtime is frozen. If we use an external runtime, Windows Update can manage security updates as long as it’s on a supported major version (generally up to 3 years).
- Installer difficulties: The installer would need to ensure that a correct version of the runtime is present on the user’s system. We cannot rely on the startup detection, as that won’t fly with distributions like chocolatey and also doesn’t work on an offline install. The .NET installer has lots of error dragons left and right, and avoiding it altogether is just the simpler way.
- I originally hoped to provide an AOT build, which is vastly superior performance-wise. All AOT builds have the runtime included. Unfortunately, WPF (the UI framework used by SyncTrayzor) is incompatible with AOT, so we don’t have them at this time. But if there’s ever a chance to get an AOT build, it will be with the self-contained runtime.
I should note that the self-contained runtime for us “only” adds about 50MB. That’s far more than I would like, but it’s also much less than the 200MB CEF dragon that annoys me a lot more…