Hacker News Reader

Comment by Kuinox | Hacker News Reader

Where does your half a second number come from ? I ran a hello world to test, the overhead is 63ms.

neuecc ran benchmark on CLI libs overhead, none reach half a second: https://neuecc.medium.com/consoleappframework-v5-zero-overhe...

> Swift does a much better job at this as interprets by default

The .NET JIT is a tiered JIT, it doesn't immediatly emit code immediatly.

View on HN

Not GP, but can confirm on my M3 Max using the hello world sample:

  $ time dotnet run hello-world.cs > /dev/null
  
  real 0m1.161s
  user 0m0.849s
  sys 0m0.122s

  $ time dotnet run hello-world.cs > /dev/null

  real 0m0.465s  
  user 0m0.401s  
  sys 0m0.065s

This is nuts. More than a decade ago Microsoft made a big deal of startup optimisations they had made in the .Net framework.

I had some Windows command-line apps written in C# that always took at least 0.5s to run. It was an annoying distraction. After Microsoft's improvements the same code was running in 0.2s. Still perceptible, but a great improvement. This was on a cheap laptop bought in 2009.

I'm aware that .Net is using a different runtime now, but I'm amazed that it so slow on a high-end modern laptop.

To be fair, this is timing early bits of a preview feature. Compiled .NET apps have much better startup perf.

They are not on Windows. As someone else pointed out, there are very likely Apple-specific shenanigans going on.

This is also a preview feature at the moment. They mention in the embedded video that it is not optimized or ready for production scenarios. They release these features very early in preview to start getting some feedback as they prepare for final release in November.

If you're trying things like that in a Mac, watch out for the notary check delay https://eclecticlight.co/2025/04/30/why-some-apps-sometimes-...

It can easily add hundreds of milliseconds in various situations you can't easily control.

There are a lot of optimizations that we plan to add to this path. The intent of this preview was getting a functional version of `dotnet run app.cs` out the door. Items like startup optimization are going to be coming soon.

maybe it's worth adding that info to the blog post :)

thanks Jared and team, keep up the great work.

I’m not really into the whole dotnet space. Except during the beta early on BSD ‘00.

It’s good that it allows scripts to run, and does packages. Simple is good

I was just curious and then surprised that it already caches compiled binaries, but that the time remained the same.

I opened an issue since I couldn't find docs that indicate what they were working on to improve the start time, and they replied:

https://github.com/dotnet/sdk/issues/49197

Ah, I didn't managed to find something that talked about what was planned for this, so I opened an issue asking for that. Is there a doc somewhere talking about it ?

For comparison, skipping dotnet run and running the compiled program directly:

  time "/Users/bouke/Library/Application Support/dotnet/runfile/hello-world-fc604c4e7d71b490ccde5271268569273873cc7ab51f5ef7dee6fb34372e89a2/bin/debug/hello-world" > /dev/null

  real 0m0.051s
  user 0m0.029s
  sys 0m0.017s

So yeah the overhead of dotnet run is pretty high in this preview version.

I can also confirm the overhead on Windows 11 (it's a simple Console.WriteLine)

  > Measure-Command { dotnet run run.cs }
  
  Days              : 0
  Hours             : 0
  Minutes           : 0
  Seconds           : 2
  Milliseconds      : 451
  Ticks             : 24511653
  TotalDays         : 2,836996875E-05
  TotalHours        : 0,00068087925
  TotalMinutes      : 0,040852755
  TotalSeconds      : 2,4511653
  TotalMilliseconds : 2451,1653

First run was around 2500ms, consecutive runs around 1300ms.

IME, windows defender hates compilers. When I run my big C++ project, Defender consumes at least 60% of the CPU. Even when exempting every relevant file, directory, and process.

Task manager doesn't show it, but process explorer shows kernel processes and the story is quite clear.

I run in a Debian arm64 container. I get 500ms consistently. It is using a cached binary, because when I add —no-build, it used the previous version. I’m not sure where it stores cached versions though.

I’ll try to compare with explicitly compiling to a binary later today.

But that’s the thing. It’s a JIT, running a VM. Swift emits native code. Big difference.

Maybe I’ll add AOT compilation for dotnet then.. Strange they didnt incorporate that though.

What command do you use ?

> But that’s the thing. It’s a JIT, running a VM. Swift emits native code. Big difference.

It's not only a JIT, you can preJIT with R2R if you need, or precompile with NativeAOT, or i think you can fully interpret with Mono.

Edit: it looks like the issue with the dotnet cli itself, which until now was not on a 'hot path'. `dotnet help` also take half a second to show up. When running a dll directly, I think it doesn't load the cli app and just run the code necessary to start the dll.

  dotnet run

Tangential, but Windows Powershell kept nagging me to download PS6, so I did it, then I had to revert it to 5.1, because running a script had a ~1 second overhead. Very annoying. For one-off runs it's often the starting time what's matter, and Powershell just got worse at that. (In the end, I settled for .bat files in a cmd.exe window, chatGPT can write any of them anyway.)

Powershell 7 was released 5 years ago, was this not an option?

On my M2 Air:

508ms with caching, 1090ms with `--no-cache`

But as others already mentioned, optimizing this seems to be pretty high priority...

Reply on news.ycombinator.com