Hacker News Reader

Hacker News

Comment by hmexx | Hacker News Reader

Full thread

hmexx

List of performance improvements is mind-boggling:

https://devblogs.microsoft.com/dotnet/performance-improvemen...

How could a mature standard library / frameworks have so much performance gains to be had?

View on HN

And in 2.0 https://devblogs.microsoft.com/dotnet/performance-improvemen...

And in 2.1 https://devblogs.microsoft.com/dotnet/performance-improvemen...

3.0 has new JIT capabilities like CPU hardware intrinsics; devirtualization; Span etc which in turn enable new techniques in the standard library.

Though 3.0 is a vast set of improvements compared to the previous two

The "core" library was designed for portability and it's not as old as the .NET used for Windows desktop development, which is very mature and very performant.

.NET Core is faster than .NET Framework

One can hardly call .NET Core "a library." It's an API surface area (.NET Standard), a cross-platform implementation of said surface area (.NET Core), a cross-platform runtime (CoreCLR), and a CLI tool (dotnet). It's already introduced numerous performance enhancements over .NET Framework (e.g., Span<T>, Memory<T>, and the runtime itself).

IMO, .NET Framework should be relegated to the dustbin of history. There is no longer a reason to use it unless you are writing legacy code (which, granted, is a legitimate reason in many cases). For greenfield projects, I hope you're using .NET Standard and .NET Core.

I believe most of these are from Span which allows doing a lot of operations (e.g. substring) without allocating a new object.

Well, in the traditional desktop space performance was not that critical as it is with cloud deployments. Also hardware intrinsics are a new toy they have available.

Seems to me it was fast enough on the desktop and uniformly responsive to events. If you wanted a Windows CRUD desktop application, really nothing better.

I suspect that the CLI and the JVM are about as fast, about 2 to 10 times slower than C++. But that .nets libraries are more performant.

.NET started to barely surpass JVM with .NET Core 2, of course this is just a general tendency, actual performance depends greatly on the problem domain, how cleverly program, what counts as "java" and "c#" and so on.

To the point. Doing it right has a much higher influence than the platform. The later might be a barrier but at that stage, that often does not matter anymore. Even PHP utilized the right way (looking at swoole) can performance wise beat other stacks.

Disclaimer: I do not generally encourage the usage of PHP :)

A lot of work was done recently with compiler optimizations and using hardware intrinsics for core functions.

Would be really nice to see performance comparisons against a chromium equivalent for the same UX.

Memory usage difference should be something like an order of magnitude better with .NET.

It's not a direct comparison, because the features aren't quite the same, but the Electron Teams app uses about 10x more memory than the relatively heavy WPF Skype for Business client that it's supposed to replace.

Would be nice to get a source for this interesting claim.

But I'm far more interested by real world user facing performance metrics such as: FPS, vsync consistency, input latency and comparing cpu and gpu usage (thus allowing to infer battery usage).

Skype has been replaced by an electron app https://electronjs.org/apps/skype

Skype for Business is entirely unrelated to Skype. It's mostly a renamed version of Lync.

Chromium is naturally bloated and heavy, what would be the goal in comparing it to WPF

The goal would be to challenge your belief.

If you were knowledgeable, you would know for example that chromium 2D rendering engine (skia) is the current state of the art. Benchmarking fps, vsync stability, input latency, etc would be enlightening. There are order of magnitude more engineers working at optimizing chromium than WPF.

I think the OP meant "bloated and heavy" in terms of the sheer size of the thing, not the performance of it. And it is. It's very difficult to use _just_ the 2D rendering part of Chromium, you bundle the whole thing, warts and all.

Binary size is only one "performance metric" and arguably the less important one.

Anyway, did you know that chromium is the GUI framework that allow you to have the smallest Binary size? Instead of bundling it like you would with most GUI frameworks (GTK, QT) you can just use the locally installed chrome instance through Carlo.

I think it's a combination of monopoly effects plus the benefits of open source: back when .NET was closed-source and only available on Windows, the only way to ship a performance improvement was if an individual developer at Microsoft could convince his boss it was worth it. And it was rarely worth it, because .NET only ran on Windows, its only customers were .NET-only enterprise shops who weren't about to move to an entirely new framework because of perf problems, and there was always a long list of feature requests that PMs would give priority to.

But now that .NET runs everywhere, it has to compete with projects that have been shipping performance improvements all along. Happily, since it's now open-source too, it can accept those changes from anyone.

It is more about backwards compatibility than anything else. Remember that .NET Framework is something that ships with an operating system (Windows) and has components built on this shared runtime: not only devtools like SSMS and Visual Studio but core Windows components like MMC applets and things like ADFS / Remote Desktop Gateway as well. This puts up a bar regarding backwards compatibility. Not only code that is written against the runtime need to be compatible, but also code hosting the runtime, debugging the runtime, the profiler API, and I could go on.

This yields some constraints in whatever is possible changing. Want to add new IL instructions? No can do. Need to change the debugger API? No can do.

Please also see this: https://news.ycombinator.com/item?id=18364032

The "proprietary" .NET was very performant. It's the new "open" one that has to catch up.

.NET Core isn't based on Mono.

You have posted something along these lines twice, it is not correct. .NET Core has been better performing than Framework from the start. You may be thinking of Mono.

Just an aside: Thanks for using "better performing" and not the non-existent word "performant." ;)

Reply on news.ycombinator.com