21–30 of 190 posts
Will the move to CoreCLR give any speed ups in practice if the release build is complied with IL2CPP anyway? On all the games that I've worked on, IL2CPP is one of the first things that we've enabled, and the performance difference between the editor and release version is very noticeable.
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.
Earlier quoted context omitted.
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 comi…
Good article but seems strange that author benchmarked debug builds first, that’s a huge “no-no” in any perf tweaking and it’s clear that authors knows this well
Setting up release benchmarks is much more complex and we develop the game in Debug mode, so it is very natural to get the first results there, and if promising, validate them in Release.
Also, since our team works in Debug mode, even gains that only speed things up in Debug mode are valuable for us, but I haven't encountered a case where I would see 20%+ perf gain in Debug mode that would not translate to Release mode.
Hard task, no doubt. Unity needs to throw everything at this problem. C# in general has gotten insanely fast by default. It's very much worth taking the time to upgrade/update.
Whilst we don't compare in size and api surface, it took us a few months to get off 472 and onto dotnet6. But once we were on dotnet6, moving to the LTS after that was relatively painless; usually a few hours of work.
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.
Earlier quoted context omitted.
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.
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…