Large performance improvements.
[0] - https://devblogs.microsoft.com/dotnet/performance-improvemen...
And then spice up the concurrency and measure memory consumption as well, a 24h test.
I know that TechEmpower gets a lot of flak for being "unrealistic", but it's easy enough to filter out the pure middleware ones. But even those I feel are "fair game" because it shows that such optimizations are possible on the runtime if needed. The story behind one of the top entrants, Just(js) talks a bit about this[3]
[0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
[1] https://github.com/TechEmpower/FrameworkBenchmarks/blob/mast...
[2] https://tfb-status.techempower.com/
[2] https://just.billywhizz.io/blog/on-javascript-performance-01...
A pretty good result for just changing a dropdown in the project settings tab.
https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...
The most obvious way to store backing fields for arbitrary objects is to have a global concurrent dictionary that stores weak keys, and a compiler-generated class to store the backing fields as the value. But then you have a performance problem of needing to do a lookup from a weak-concurrent-dictionary every time you access any extension backing field.
The higher-performance alternative would be a second shadow variable in code that uses the extension backing fields. Do your dictionary lookup, then cache the backing-fields-object so you don't need to redo lookups for it. But that would be function-local.
If the extension property doesn't need a new backing field, it's trivial, you're just making a new getter and setter function pair.
twinBasic https://twinbasic.com
