ā Why is C# so slow on Linux? How can I speed it up?
Just "Hello World" take almost three seconds to execute.
What can I do to speed it up?
65 Replies
On the same hardware, C++ Hello world takes only a few milliseconds:
`
compile in native if you want to compare with c++
How do I do that? I don't see any options on
dotnet built that look like they change the target.add
<PublishAot>true</PublishAot> in your csproj and do a dotnet publish
the compilation will be longerLooks like ARM isn't supported.
Yeah, no support: https://github.com/dotnet/runtimelab/issues/833
GitHub
Support for ARM32 in NativeAOT Ā· Issue #833 Ā· dotnet/runtimelab
Is there any plans to support ARM32? Basically so that you from a PC running Linux(amd64) could do: dotnet publish -r linux-arm -c release Or could you already today compile applications for ARM32 ...
Looks like the issue has been open for a couple of years, and the one guy working on it gave up this past April.
oh what are you to be on 32 bit ?
have you tried running the C# output directly
instead of going through
dotnet run which is going to result in a lot of overheadoh 
/usr/bin/ld: cannot find -lstdc++: No such file or directory
/usr/bin/ld: cannot find -lstdc++: No such file or directory32 bits, yeah. I think most people run 32-bit on Raspberry Pi
oh yeah on raspi
you should prefer not to
for one it will make .NET quite a bit faster
running directly helps, but sitll about 50 times slower than C++:
Are you sure? On 64-bit Intel, it's even slower!
if it took 5 seconds tha is almost cerainly because it was building it
the last one is native AOT
Oh, good catch. with
--no-build it is "only" 1775 milliseconds.to be clear, everthing you are seeing is expected
Expected to be slow? LOL
yes
if 115 milliseconds to run a hello world is not fast enough then yeah that's what you get with .NET
and, yes,
dotnet SDK adds a lot of overheadfor example on ubuntu
if you need instant startup then switch to a 64-bit operating system and use native AOT
the 32-bit targets are also not very well optimized
especially 32-bit arm, it is missing a lot of huge JIT enhancements
ubuntu x64 without aot
What other disappointments are "expected"?
you are free to use C++ if shaving off 100 milliseconds matters more to you than having C#
It's also just 100 milliseconds of start up.....
fast enough for me
if how many milliseconds it takes to run hello world is your primary factor in choosing a programming language then yeah i'd probably recommend C or assembly
So, it's expected that it's slow, and tough shit if you don't like it? It's like the software industry is giving up on itself.
do you write software professionally
or as a hobbyist
Yep, since 1985.
it takes my shit like 3 minutes to get published to azure, so i really couldn't care less if the application takes 100ms to start instead of 50
I'm not normally ocncerned iwth startup, but when it's so long that it dominates processing time on a small workloads. In actuality, I have a system that runs on some input. Beforehand, we don't know if the input is large or small. If it's large, great -- a 2-seconds startup doesn't matter much becuase processing takes a while. If it's small, then processing takes far less time than startup and we actually end up falling behind.
now that 3 minutes is frustrating, but i don't go around calling programming languages bad and disappointing because they don't run hello world fast enough
why is your program restarting for every input
I think the service script is spawning
dotnet run, so it'll certainly help to directly run the image. The startup time is still a bit of a concern.
I thiiiiink I've done the math right, but we'd need it to be less than 75 milliseconds to not be an issue.well my hello world ran in 65 ĀÆ\_(ć)_/ĀÆ
im sure you could get it faster with native aot
or you could refactor whatever your use case is so the program doesn't have to run once for every input
i personally would not have .NET as my first choice for a component of a shell script. i'd either write the entire script as a .NET program or use another lang
Sure, if refactoring large systems was free, we'd already have done that. Fact is, we're in the midst of rearchitecting a large legacy system. Maybe one day it'll be a full-blown service, but until then we run a process against available input in batches.
Shell script?
whatever kind of script you're running
Maybe you wouldn't, but I don't see how that addresses this problem.
idk what the "problem" is at this point. that .NET's perf disappoints you?
you can look into native aot to make the startup time faster
The problem is that there's a significant cost to starting up a dotnet app. Sorry, I thought I had made that clear before. Maybe another problem is that you're apathetic to the issue.
here's hello world with native aot
i personally do not find myself or hear about others repeatedly invoking .net apps in scripts. that's why i'm apathetic
you're using a tool that's not optimized for your use case and then complaining that the industry is in decline when you get unsatisfactory performance
i mean .NET startup has never been faster than it is in 2023
.NET has existed since 2002
I'm wondering if the industry is in decline because people expect bad performance, and expect that very common platforms are unsupported.
this is one of the tradeoffs of this technology and it always has been
yeah that too, i'm not even mentioning the fact that even without native aot, the performance is to your standards
"bad performance" is subjective
and .net was windows only until .net core
if you want blazing fast performance and code that's portable to every platform, write in C
this is not a novel issue
C# is pretty performant
to my standards?
75ms right
i am not sure why you are acing like this is something outrageous in 2023
my hello world ran in 65 without native aot, 10 with. obviously there'll be a hardware difference, but i doubt native aot will be over 75 on your hardware
Yep, 75 ms. It's almost twice that.
with native aot?
native aot doesn't work on my primary OS. I mentioned this above.
sorry, must have missed it
not sure what you want to hear at this point
i mean i am sorry that 32-bit is not a focus anymore
especially Arm32 which newer processors do not support at all
and embedded is not a strong point for .NET
so you can imagine why their priorities are Arm64 and x64 which are ubiquitous in client and server scenarios
AOT is fast enough, but it would only help for about 30% of our fleet.
all i can really recommend without AOT is to make sure you're running the executable directly and not going through
dotnet run like was mentioned already
It'll probably be another 6 months before we have a chance at upgrading the fleet, but I have a few things to try until then so thanks for that.
i'm sure there are more in-depth improvements to perf that you can make, but i'm not aware of them
presumably your application is more complex than hello world
have you tried using ReadyToRun
ReadyToRun might help, but you start running into then technical limitations of needing to start up a runtime
it is inherently going to take more time to start than C++, which has minimal initialization to do in comparison
Expected to start up slower because of JIT overhead
Once the app has warmed up, there will not be much difference
For things like desktop and server apps, the little extra startup time is not an issue
And no one is apathetic to that issue, otherwise there wouldn't be AOT or ReadyToRun
Apparently you have been a professional since 1985 yet you are profiling a Hello World application lol
Yep, because startup of even a trivial app was taking more than two seconds. Profiling my own app, in its short-run case, takes just as long.
Was this issue resolved? If so, run
/close - otherwise I will mark this as stale and this post will be archived until there is new activity.