Hopefully they also take time to upgrade their archaic forum software. Even a basic search is a terrible experience. For a company fighting for developer mindshare, it’s surprisingly bad.
Pretty much this. Add in that in a relatively small project in which you include a few asset store items along with your own code the code build time might be 15s, followed by 15s to launch the editor into play mode; now they're talking about some improvements that might shave a few ms off the time, or a multi-year project (which might actually make a difference); but which probably will be implemented as poorly as everything else they've done.
In another year they'll be bored of this performance upgrade, and they'll start something else up.
On some of their other attempts: IL2CPP has performance improvements, but it also has issues such as on a select % of laptops it'll just cause a random crashes (even in a very basic project). They tried adding DOTS for graphical improvement rendering a lot of items, but then just sort of semi-abandoned it to work on other tasks.
Let's not even get started on them splitting the rendering pipelines.
Wow I don’t envy the team tasked with making this happen.
It’s been a long time coming. It’s unfortunate to learn there isn’t more progress towards this end already. I was looking for news from Unity about a migration as soon as Microsoft announced .NET 5 as the successor to both .NET Core and .NET Framework.
Nevertheless, better late than never. Here’s hoping they don’t run into too much internal resistance, as I’m sure they will be stepping on the toes of literally every other team at Unity until they get this done.
12 comments
[ 2.7 ms ] story [ 39.5 ms ] threadNGEN was been around since version 1.0, granted only does dynamic linking and still pings back into the JIT for reflection based code.
Windows 8 introduced MDIL, with Bartok compiler, based on Singularity infrastructure.
Windows 10 introduced .NET Native for UWP scenarios, based on Midori and originally known as Project N.
Mono has always had support for AOT, is used by Xamarin on mobile devices, and is actually what Blazor relies on for WebAssembly AOT.
Then there were projects like CosmOS, having their own IL to native compiler as well.
What Native AOT brings into .NET 7, is finally some consistency in Microsoft offerings for AOT compilation.
They're on Discord, Matrix, IRC.
It's understandable that it's going to take a long time but nevertheless disappointing.
In another year they'll be bored of this performance upgrade, and they'll start something else up.
On some of their other attempts: IL2CPP has performance improvements, but it also has issues such as on a select % of laptops it'll just cause a random crashes (even in a very basic project). They tried adding DOTS for graphical improvement rendering a lot of items, but then just sort of semi-abandoned it to work on other tasks.
Let's not even get started on them splitting the rendering pipelines.
How does Unity coupe with pauses?
In two ways, by using a somewhat modern GC, mark and sweep is like "introduction to tracing GC" 101 CS. So pauses are somewhat minimal.
.NET also supports value types and explicit memory management, if one wants to go down that route.
Which they do, with their C# subset for high performance code named Burst.
Maybe you know Mike Acton of Data Oriented fame, he is one of the lead architects at this infrastructure.
It’s been a long time coming. It’s unfortunate to learn there isn’t more progress towards this end already. I was looking for news from Unity about a migration as soon as Microsoft announced .NET 5 as the successor to both .NET Core and .NET Framework.
Nevertheless, better late than never. Here’s hoping they don’t run into too much internal resistance, as I’m sure they will be stepping on the toes of literally every other team at Unity until they get this done.