Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unity's Mono problem: C# code runs slower than it should

marekfiser.com

Post reply on HN
Print view View original

11–20 of 190 posts

Re: Unity's Mono problem: C# code runs slower than it should

#11

Post by eole666 »

999900000999 wrote: post #7
makotech221 wrote: post #2

Yeah I think Unity just doesn't have the technical skillset anymore to make the migration to coreclr. It keeps getting delayed and their tech leads keep dropping out. Might I suggest https://github.com/stride3d/stride , which is already on .net 10 and doesn't have any cross-boundary overhead like Unity.

Stride has a fraction of the features as unity. Godot is the only real open source competitor, their C# support is spotty. If I can't build to Web it's useless for game jams as no one should be downloading and running random binaries. A real sandbox solution with actual GPU support is needed.

Godot 4 C# web export is coming soon : https://github.com/godotengine/godot/pull/106125

Re: Unity's Mono problem: C# code runs slower than it should

#13

Post by teraflop »

WillPostForFood wrote: post #6
makotech221 wrote: post #2

Yeah I think Unity just doesn't have the technical skillset anymore to make the migration to coreclr. It keeps getting delayed and their tech leads keep dropping out. Might I suggest https://github.com/stride3d/stride , which is already on .net 10 and doesn't have any cross-boundary overhead like Unity.

Progress has been painfully slow, but Unity does seem to be moving forward. Unity updates on their plans and progress: 2022 - officially announced plans to switch to CoreCLR - https://unity.com/blog/engine-platform/unity-and-net-whats-n... 2023 - Tech update - https://unity.com/blog/engine-platform/porting-unity-to-core... Unite 2025 - CoreCLR based player scheduled for Unity 6.7 in 2026 - https://digitalproduction.c…

Maybe they are making progress. But given that they first started talking about this in 2018, and then in 2022 they announced that they were planning to release a version with CoreCLR in 2023, and then in 2024 they said it would be in beta in 2025, and now in 2025 they're planning to release it as a technical preview in 2026, but they're still talking about an "internal proof-of-concept" as though it's something coming in the future...

As an outsider, it certainly seems like there's reason for skepticism.

Re: Unity's Mono problem: C# code runs slower than it should

#14

Post by eterm »

Rochus wrote: post #3

That's interesting. I made measurements with Mono and CoreCLR some years ago, but only with a single thread, and I came to the conclusion that their performance was essentially the same (see https://rochus.hashnode.dev/is-the-mono-clr-really-slower-th... ). Can someone explain what benchmarks were actually used? Was it just the "Simple benchmark code" in listing 1?

What's going on with the Mandelbrot result in that post?

I don't beleive such a large regression from .NET framework to CoreCLR.

Re: Unity's Mono problem: C# code runs slower than it should

#15

Post by Rohansi »

Rochus wrote: post #8
Rohansi wrote: post #5

The article doesn't cover it but the GC being used by Unity also performs very poorly vs. .NET, and even vs. standalone Mono, because it is using the Boehm GC. Last I heard Unity has no plans to switch IL2CPP to a better GC [1]. It'll be interesting to see how the CoreCLR editor performs. With that big of a speed difference the it might be possible for games to run better in the editor than a standalone Mono/IL2CPP b…

> because it is using the Boehm GC For what reason? Mono has a pretty good precise GC since many years.

Yes, SGen should be a lot better, but Unity cannot use it because they hold and pass raw pointers around everywhere. That's fine for Boehm but not possible with SGen. They're working on fixing this already but not sure why they aren't planning a move to a better GC.

Re: Unity's Mono problem: C# code runs slower than it should

#16

Post by 999900000999 »

eole666 wrote: post #11
999900000999 wrote: post #7

Earlier quoted context omitted.

Stride has a fraction of the features as unity. Godot is the only real open source competitor, their C# support is spotty. If I can't build to Web it's useless for game jams as no one should be downloading and running random binaries. A real sandbox solution with actual GPU support is needed.

Godot 4 C# web export is coming soon : https://github.com/godotengine/godot/pull/106125

We'll see when it actually ships.

I've seen this issue before, they're making progress but theirs no firm release date.

Plus you then have to extensive testing to see what works in Web builds and what doesn't. I REALLY enjoy vibe coding in Godot, but it's still behind Unity in a lot of ways.

Re: Unity's Mono problem: C# code runs slower than it should

#17

Post by Rohansi »

llmslave2 wrote: post #9
Rohansi wrote: post #5

The article doesn't cover it but the GC being used by Unity also performs very poorly vs. .NET, and even vs. standalone Mono, because it is using the Boehm GC. Last I heard Unity has no plans to switch IL2CPP to a better GC [1]. It'll be interesting to see how the CoreCLR editor performs. With that big of a speed difference the it might be possible for games to run better in the editor than a standalone Mono/IL2CPP b…

Re. the editor speedup, it should outright eliminate the "domain reload" thingy that happens because all of the C# needs to be unloaded and reloaded in response to a change.

Pretty sure that will still be there? It'll be different because CoreCLR doesn't really have AppDomains but it will still need to unload old assemblies and reload them all again. That's the only reliable way to reset everything into a clean state.

Re: Unity's Mono problem: C# code runs slower than it should

#18

Post by llmslave2 »

Rohansi wrote: post #17
llmslave2 wrote: post #9

Earlier quoted context omitted.

Re. the editor speedup, it should outright eliminate the "domain reload" thingy that happens because all of the C# needs to be unloaded and reloaded in response to a change.

Pretty sure that will still be there? It'll be different because CoreCLR doesn't really have AppDomains but it will still need to unload old assemblies and reload them all again. That's the only reliable way to reset everything into a clean state.

But only the assemblies that changed right? Or would it still be all of them?

Re: Unity's Mono problem: C# code runs slower than it should

#19

Post by bentt »

WillPostForFood wrote: post #6
makotech221 wrote: post #2

Yeah I think Unity just doesn't have the technical skillset anymore to make the migration to coreclr. It keeps getting delayed and their tech leads keep dropping out. Might I suggest https://github.com/stride3d/stride , which is already on .net 10 and doesn't have any cross-boundary overhead like Unity.

Progress has been painfully slow, but Unity does seem to be moving forward. Unity updates on their plans and progress: 2022 - officially announced plans to switch to CoreCLR - https://unity.com/blog/engine-platform/unity-and-net-whats-n... 2023 - Tech update - https://unity.com/blog/engine-platform/porting-unity-to-core... Unite 2025 - CoreCLR based player scheduled for Unity 6.7 in 2026 - https://digitalproduction.c…

Nice link, thanks.

Re: Unity's Mono problem: C# code runs slower than it should

#20

Post by to11mtm »

Rochus wrote: post #3

That's interesting. I made measurements with Mono and CoreCLR some years ago, but only with a single thread, and I came to the conclusion that their performance was essentially the same (see https://rochus.hashnode.dev/is-the-mono-clr-really-slower-th... ). Can someone explain what benchmarks were actually used? Was it just the "Simple benchmark code" in listing 1?

I think a lot of the devil is in the details, especially when we look at NET8/NET10 and the various other 'boosts' they have added to code.

But also, as far as this article, it's noting a noting a more specific use case that is fairly 'real world'; Reading a file (I/O), doing some form of deserialization (likely with a library unless format is proprietary) and whatever 'generating a map' means.

Again, this all feels pretty realistic for a use case so it's good food for thought.

> Can someone explain what benchmarks were actually used?

This honestly would be useful in the article itself, as well as, per above, some 'deep dives' into where the performance issues were. Was it in file I/O (possibly Interop related?) Was it due to some pattern in the serialization library? Was it the object allocation pattern (When I think of C# code friendly for Mono I think of Cysharp libraries which sometimes do curious things)? Not diving deeper into the profiling doesn't help anyone know where the focus needs to be (unless it's a more general thing, in which case I'd hope for a better deep dive on that aspect.)

Edited to add:

Reading your article again, I wonder whether your compiler is just not doing the right things to take advantage of the performance boosts available via CoreCLR?

E.x. can you do things like stackalloc temp buffers to avoid allocation, and does the stdlib do those things where it is advantageous?

Also, I know I vaguely hit on this above, but also wondering whether the IL being done is just 'not hitting the pattern'. where a lot of CoreCLR will do it's best magic if things are arranged a specific way in IL based on how Roslyn outputs, but even for the 'expected' C# case, deviations can lead to breaking the opt.

Post reply on HN