Look, nobody’s going to argue .NET is sexy, but the truth of the matter is that it’s quite popular in less visible circles, so any new release is going to have a big impact on a ton of people and product. In other words, performance improvements in .NET 11 are going to matter.
In contrast, .NET 11 is actually one higher, one louder. The sections that follow are full of real improvements. A bounds check removed, an allocation that no longer happens, a lock that isn’t taken, a loop that runs in fewer cycles than it did a year ago, a comparison folded to a constant here, a redundant check hoisted out of a loop there, a couple of instructions fused into one, a syscall sidestepped, an array copy handed off to SIMD, and on and on. That’s how real performance work goes, accumulating gain after gain, each compounding on the last, until the whole thing is measurably, provably louder. And so, in this post, as I’ve done in past years with .NET 10, .NET 9, .NET 8, .NET 7, .NET 6, .NET 5, .NET Core 3.0, .NET Core 2.1, and .NET Core 2.0 before it, we’ll take an unhurried tour through hundreds of them.
↫ Stephen Toub at Microsoft’s Dev Blogs
My eyes glaze over at all of this, but even here on OSNews, there’s going to be countless people working with .NET at their jobs.
I use .net sometimes in my job and one of my colleagues uses it exclusively for all her projects, These include a system that takes the data in a 3D model and processes it to create output files for machines that roll steel, This is quite performance intensive so our customers and us always benefit from .net performance improvements. I am also in the process of rewriting one of our legacy C systems (The one that actually creates the 3D components in the model) in .net so this will be nice to have there too. We make all our internal tools in .net as is one of our API’s. So just a few examples of real world impacts of .net performance improvements, I’m sure there are hundreds (likely thousands) more examples in our company alone that will benefit, I often feel like the focus is too much on adding new features than just raw optimization.
MarkHugher,
I agree. A language ought to be fairly simple and small.
The HR block desktop software is a .net application and comes in at a 603MB compressed….
For better or worse they bundle the .net runtime. Most of this is pure bloat. This is insanity, but as more software gets packaged into gigantic bundles, this is the fate of software distribution. So with this in mind, I think language designers need to start breaking apart the language core from ancillary dependencies. This way software bundles don’t end up carrying hundreds of megabytes of useless bloat.
Coming from C, I look at the release notes for each version of .net and I find it hard to keep up sometimes on the new features, I do try though 🙂 And yes, The size of the created program is huge. As you say, An app that would fill a CD is crazy.
I did look at some systems that compile the C# to native code, I didn’t get far with it but might be something I revisit later.
The C version of my legacy system comes in at about 20MB, I am really curious to see what my C# .net rewrite comes in at to do the same job.
MarkHughes,
I’m curious about things like that too. I don’t expect code density to be so drastically different In principal. Huge binaries are rarely justified by actual coding logic. C# might have to carry a bit more overhead because of reflection. I think what’s caused software to explode in size the most is the bundling of gigantic support frameworks with the majority of the code not being used at all. Obviously unused resources ought to be stripped out for deployment. However it may not be the developer’s fault when frameworks are designed to be one giant bundle.
It is not necessary to be bundled with the .net runtime if you are AOT-focused. This is the solution to this problem. Check my repo of a network utility that I remastered from a C tool: https://github.com/kzagoris/winmtr-remaster. The app itself which is a GUI app it is ~18 MB, and the cli version is ~1.8 MB. The modern c#/.net has the tools to minimize that problem.
.NET has been on a pretty impressive and indeed relentless pursuit of performance ever since the introduction of .NET Core. It is extremely impressive how far they have come.
I have always liked .NET and was even an early Mono advocate.
Resource management is easy, and the base library of .NET is so extensive. It is VERY batteries included. And code re-use across use-cases is amazing (eg. you can easily create libraries and business logic that you use unmodified on the web, in embedded, on the server, on the desktop, or wherever). The level of programmer productivity is hard to beat. And I have always loved that .NET was designed from the beginning to support interoperability between multiple languages. I have even written a couple toy languages for .NET and they are much more than toys because of the ecosystem they inherit.
But almost everybody uses C# and C# as a language has gotten complex. It is not quite C++ but it is closer than I would like.
The real kicker for me though has been containers. The size of the .NET runtime and base library are no big deal when shared across all your apps on a server. But if you have to deply the full .NET environment in a container for every tiny app or microservice, that starts to be a real drag.
The same problem exists around the trend away from server side to client side applications on the web. But Microsoft have done some impressive things to make that work reasonably well.
Have you tried F# then?
Any luck with assembly trimming of published applications?
I have used F# but not for anything overly serious. Trimming is a challenge as F# makes heavy use of reflection. You can use the –reflectionfree compiler flag which helps.
I’m one of those people that likes .Net. I’ve used it for projects, games, and even used C# with Cosmos to make an OS with my kids