4 ms·

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 hal

by Kuinox 1y ago

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-overhead-native-aot-compatible-cli-framework-for-c-8f496df8d9d1 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.

bouke 1y ago
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
- masfuerte 1y ago
  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.
  - thatnerdyguy 1y ago
    To be fair, this is timing early bits of a preview feature. Compiled .NET apps have much better startup perf.
  - toyg 1y ago
    They are not on Windows. As someone else pointed out, there are very likely Apple-specific shenanigans going on.
  - doomroot13 1y ago
    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.
- viraptor 1y ago
  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-launch-extremely-slowly/ 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.
- jaredpar 1y ago
  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.
  - evntdrvn 1y ago
    maybe it's worth adding that info to the blog post :) thanks Jared and team, keep up the great work.
  - jbverschoor 1y ago
    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.
    - Kuinox 1y ago
      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 https://github.com/dotnet/sdk/issues/49197
  - Kuinox 1y ago
    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 ?
- deleted 1y ago
  [deleted]
- bouke 1y ago
  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.
jbverschoor 1y ago
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.
- Kuinox 1y ago
  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.
  - jbverschoor 1y ago
    dotnet run
bmacho 1y ago
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.)
- PaulWaldman 1y ago
  Powershell 7 was released 5 years ago, was this not an option?
andix 1y ago
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.
- mystified5016 1y ago
  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.
utf_8x 1y ago
On my M2 Air: 508ms with caching, 1090ms with `--no-cache` But as others already mentioned, optimizing this seems to be pretty high priority...

by Kuinox 1y ago

bouke 1y ago

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

masfuerte 1y ago
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.
- thatnerdyguy 1y ago
  To be fair, this is timing early bits of a preview feature. Compiled .NET apps have much better startup perf.
- toyg 1y ago
  They are not on Windows. As someone else pointed out, there are very likely Apple-specific shenanigans going on.
- doomroot13 1y ago
  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.
viraptor 1y ago
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-launch-extremely-slowly/ 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.
jaredpar 1y ago
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.
- evntdrvn 1y ago
  maybe it's worth adding that info to the blog post :) thanks Jared and team, keep up the great work.
- jbverschoor 1y ago
  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.
  - Kuinox 1y ago
    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 https://github.com/dotnet/sdk/issues/49197
- Kuinox 1y ago
  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 ?
deleted 1y ago
[deleted]
bouke 1y ago
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.

jbverschoor 1y ago

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.

Kuinox 1y ago
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.
- jbverschoor 1y ago
  dotnet run

bmacho 1y ago

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.)

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

andix 1y ago

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.

mystified5016 1y ago
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.

utf_8x 1y ago

On my M2 Air: 508ms with caching, 1090ms with `--no-cache` But as others already mentioned, optimizing this seems to be pretty high priority...