Why do .NET applications have at least a one-second startup delay?

Question

I was seeking a language with the following parameters:

1. Simple and readable syntax.

2. Capability to effortlessly create Windows user interfaces.

3. Native support for Windows applications.

4. Superior performance and quick startup times.

5. Portability, eliminating the need for extensive installations like the 10-20 GB Visual Studio IDE.

6. It should already be widely used and possess a substantial community.

I discovered that VB6 meets my needs, but unfortunately, it is no longer supported. Therefore, I tried VB .NET. I found the transition to be quite easy, and the VB code was far more readable and concise compared to C#/C++. As I had mentioned, I did not want to install anything, so I did not try .NET 6 and 7. I aim to utilize built-in tools like vbc.exe or portable tools as much as possible. However, the problem with .NET framework is that the startup time remains consistently between 1-2 seconds, regardless of the code's weightiness or the language used (VB or C#). In contrast, VB6 applications start immediately. Here's an example that is written in VB .NET:

Imports System.Windows.Forms
Imports System.Drawing

Public Class Form1
    Inherits Form

    Private WithEvents button As New Button()
    Private WithEvents textBox As New TextBox()

    Public Sub New()
        button.Text = "Browse"
        button.Location = New Point(10, 10)
        Me.Controls.Add(button)

        textBox.Location = New Point(10, 40)
        Me.Controls.Add(textBox)
    End Sub
End Class

Module Module1
    Sub Main()
        Application.Run(New Form1)
    End Sub
End Module

What I did:

1.

CD C:\Windows\Microsoft.NET\Framework64\v4.0.30319 
NGEN update

2. I tried various options for the vbc.exe (and csc.exe) compilers, such as /optimize[+|-] and /platform.

3. Different versions of the .NET framework (both 32-bit and 64-bit) including versions 2, 3.5, and 4.x.x.

4. Using msbuild.exe to compile my application with the following command:

msbuild /property:Configuration=Release;UseDotNetNativeToolchain=true MyFile.vbproj,

here is content of MyFile.vbproj:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" Sdk="Microsoft.NET.Sdk" >
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net5.0</TargetFramework>
    <UseDotNetNativeToolchain>true</UseDotNetNativeToolchain>
  </PropertyGroup>

  <ItemGroup>
    <Compile Include="DiCalc.vb" />
  </ItemGroup>

<Target Name="Build">
  <Vbc Sources="@(Compile)" OutputAssembly="DiCalc.exe" TargetType="WinExe"/>
</Target>


</Project>

Thanks in advance.

Update 1:

1. I do not have any antivirus software installed on my system. Both the SmartScreen filter and Windows Defender are currently disabled.
2. I do not use any shared network folders. Actually, I tested it on an M.2 NVMe SSD.

Update 2: Here is more detailed test:

VB6 and VB.NET-x86 video

VB.NET-x64 video

test.vb

Imports System.Windows.Forms
Imports System.Drawing

Public Class Form1
    Inherits Form
    Private button As New Button()


    Public Sub New()
        Me.BackColor = Color.FromArgb(14, 14, 14)
        Me.ForeColor = Color.FromArgb(240, 240, 240)
        
        button.Text = "Browse"
        button.Location = New Point(10, 10)
        button.BackColor = Color.FromArgb(14, 14, 14)
        button.ForeColor = Color.FromArgb(240, 240, 240)
        Me.Controls.Add(button)

    End Sub
End Class

Module Module1
    Sub Main()
        Application.Run(New Form1)
    End Sub
End Module

Compilation command:

x64

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\vbc.exe /t:winexe /platform:x64 /out:VB.NET-x64.exe test.vb

x86

C:\Windows\Microsoft.NET\Framework\v4.0.30319\vbc.exe /t:winexe /platform:x86 /out:VB.NET-x86.exe test.vb

Average delay:

VB.NET-x64.exe => ~320 ms
VB.NET-x86.exe => ~650 ms
VB6-x86.exe    => ~80 ms

So VB6 startup time is 4x to 8x faster than VB.NET.

Note: To see the actual delay make sure animations are disabled and the single-click in explorer is enabled through Folder Optiona.

Update 3: I downloaded the .NET 8 SDK zip archive to test it and determine if Ahead-Of-Time (AOT) compilation will improve the startup time, similar to VB6. Here is the content of the .vbproj file:

<Project Sdk="Microsoft.NET.Sdk" >
  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>net8.0-windows</TargetFramework>
    <UseWindowsForms>true</UseWindowsForms>
    <PublishAot>true</PublishAot>
    <StripSymbols>true</StripSymbols>
    <PublishTrimmed>false</PublishTrimmed>
    <SelfContained>true</SelfContained>
    <PublishReadyToRun>true</PublishReadyToRun>
  </PropertyGroup>
<ItemGroup>
    <PackageReference Include="System.Windows.Forms" />
</ItemGroup>
</Project>

Compilation command:

dotnet.exe build /p:Configuration=Release /p:UseNativeAOT=true

The result is an app that's roughly 150MB in size, but with the same delay as before.

Answer 1

First of all, NONE of my vb.net applications exhibit such delays on startup.

If you create a vb.net windows .net framework forms application, then startup time shows no delay, and NOT EVEN A PERCEPTIBLE startup delay.

So, let's do a hello world:

File->New Project.

This one:

Thus, let's build that classic "hello world" example.

We drag a button on the form, and thus write this code:

And then f5 to run..

(actually, we use the mouse and hit the start button).

We see this, and see VERY little delay:

Of course, we running this from Visual Studio, but let's right click on the project, choose "Open folder in explore", and then run the .exe file from the Windows Explorer (not running/launching from Visual Studio). So, let's launch the .exe file from the Windows Explorer (or even the command prompt).

So, we now have this folder, and when I click on the .exe file, the form launches without ANY perceptional delay at all.

So, I see this:

Now, I'm using screen to gif, and that runs at 15 frames per second, so what you see is somewhat slower effects and response time than doing this on your own computer.

But, screentogif (the screen capture software I used) DOES SHOW a round circle when I click the mouse. So, when I double-click on the .exe file (to run it), then can see the mouse click "circle" from screentogif software flash two times.

Now, I did not count the number of video frames captured, but it doesn’t look more then 1 frame delay. So, that is AT LEAST 1/15th of a second, but in fact very likely LESS time.

In other words, we are under 1/10th of a second for that .exe file to load and run......

And even if I create the above same project with .net core, once again, I can't see nor find any perceptible startup delay here.

So, I am not aware that .net has some big delay, or startup time, and it really never need seem to run any much different in regards to startup times then say compared to VB6 .exe's startup times.

I suppose on really weak older hardware, then VB6 might have a better startup time, but it should not be really noticeable, and it FOR SURE is not in the 1-2 second range. For a VERY large .net application, then on first run, you can often see delays, since that .exe is actually NOT YET compiled to machine code!!! When you build a .net .exe, that exec does not (yet) actually have compiled machine code). It has what is called p-code (just like VB5/6 had). This so called "IL" code (intermediate language or so called "p-code) is not yet compiled, and such compiling of code ONLY occurs when you FIRST run the code!!! So, .net has a JIT (Just In Time compiler system), and the code compiles as you use it, and on first run. However, as I pointed out, for the above simple and small applications, no such delays should be perceptible at all on startup.

And that compiling only need to occur one time, after that, the compiled code is remembered. This IS NOT ANYTHING TO DO WITH DISK caching and LOADING of the program - it is ONLY specific to the JIT system used to compile and run the .exe file.

This suggests some other issue is at play here, such as your virus software scanning and preventing the .exe from launching until the virus scan software can finish checking the .exe file first.

Or, there is some network shared folder you are using here, or some other big detail you not shared with us.

In fact, as above shows, hitting f5 from Visual Studio 2022 does not even take 2 seconds! But hitting f5 is a full compile, + build, and then run. (multiple operations, and one's that a user will never see).

So, running the resulting .exe file created from that VS project by a double click on the file, or typing in the .exe file name from the command prompt MOST CERTAINLY launches, and runs in WELL UNDER ONE second, let alone two seconds.

And keep in mind that I’m running this on a laptop, and not a high-end laptop, let alone a better and more powerful desktop computer.

And, if I create a .net Core Winforms .exe, then once again, I don't perceive any delay. I certainly see more files in the .bin folder as a result of the build, but I don't see a change nor increased loading times when using .net core. I could perhaps try a cold start (re-boot), but I doubt it will make any difference.