-
awesome-dot-net-performance
A curated list of awesome .NET Performance books, courses, trainings, conference talks, blogs and most inspiring open source contributors. Inspired by awesome-... stuff.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
runtimelab
This repo is for experimentation and exploring new ideas that may or may not make it into the main dotnet/runtime repo.
-
corert
Discontinued This repo contains CoreRT, an experimental .NET Core runtime optimized for AOT (ahead of time compilation) scenarios, with the accompanying compiler toolchain.
-
Vrmac
Vrmac Graphics, a cross-platform graphics library for .NET. Supports 3D, 2D, and accelerated video playback. Works on Windows 10 and Raspberry Pi4.
-
I would look at adding LMAX Disruptor to this list. It can run circles around stuff scattered across TPL usages. Doesnt fit every use case, but its really incredible when it does fit. I was able to build a toy project that handles millions of user events per second on a single thread using this.
Getting your application aligned with the NUMA model makes way more difference in performance than anything else.
https://github.com/disruptor-net/Disruptor-net
What does AOT have to do with benchmarks that don't use AOT and report great performance?
Also you're dramatically overstating how mature AOT is for dotnet
https://github.com/dotnet/runtimelab/tree/feature/NativeAOT
>This repo is for experimentation and exploring new ideas that may or may not make it into the main dotnet/runtime repo.
> AOT compilation? I'll believe it when they'll release it, until then, it's all speculation
Devil's in the details, but there -is- AOT compilation[0]. While it hasn't been released as an official product, it has been used for a few projects including a commercial game [1]. And yes, they're looking into the next steps to make it a 'released' thing.[2]
[0] - https://github.com/dotnet/corert/
[1] - https://github.com/dotnet/corert/issues/8233#issuecomment-65...
[2] - https://github.com/dotnet/runtimelab/tree/feature/NativeAOT
Interfaces don’t always have boxing penalty. Write generic code, use the interface as generic type constraint, and the interface will work without virtual calls, boxing, or any other runtime overhead.
Example of that approach: https://github.com/Const-me/Vrmac/blob/1.2/Vrmac/Draw/Main/I...
What are you talking about ? I had a problem with Gradle failing to work with OpenJDK just a few months ago [1]
We literally had software in production that wouldn't work when you upgraded the JVM and their official documentation said it wouldn't work - this was in JVM 5 -> JVM 6 days.
[1] https://github.com/gradle/gradle/issues/8681