The results of upgrading RavenDB to .NET Core 3.1
time to read 1 min | 67 words
Last week we upgraded our internal production servers to run RavenDB under .NET Core 3.1. Here are the CPU metrics over the past two weeks.
It isn’t the only change in the deployed version, but none of the others were about performance 
.
Comments
Is this an update from .Net 4.7 or from .Net Core 2.2/3.0 ?
I would very much like to read an analysis of what accounts for the change.
@Tyler I'm guessing lot less object instantiations and GC. Heavy use od Span and switching to System.Text.Json from Newtonsoft.Json.
@Adrian I believe is .Net Core upgrade, not from framework. Ever since release of RavenDB 4, it is away from the .net framework.
@Ayende did Json serializer changed to
System.Text.Jsonnow? I know in RavenDB 3.5 it uses forked version of Newtonsoft.Json. In RavenDB 4 I remember I didn't see forked version any more but not exactly sure if still use Newtonsoft.Json.Database side switch to
System.Text.Jsonprobably not that big impact, client side switch it will be breaking change for some of user I think. When they have custom converter.Jason correct me if i am wrong, but this seems to be ONLY the result of changing the runtime, not by changing to Span<T> or using System.Text.Json instead of Newtonsoft.Json ( Raven Uses their own Binary kind of JSON implemented in Sparrow ) Since RavenDB uses unsafe c# and pointers a lot already Span<T> does not give you much except maybe at some intersection points with some networking apis.
I am however really happy that they did not incur performance regressions due to the ..... extreme kinds of optimizations they did ( tailoring C# code to match JIT behaviour ) because that was likely to break as the JIT is constantly evolving ( I just had a nasty issue like that going from 3.0 to 3.1 in some low level audio processing code )
Did you plan to upgrade the .NET core runtime in RavenDb cloud also?
Lorenzo,
Yes, we'll probably do a roll out of that during Feb.
Adiran,
This is from .NET Core 2.2
Tyler, .NET Core 3.1, mostly, I think. We haven't done any perf work to account for this.
Piotr,
Absolutely none of that, actually. We moved to .NET Core 3.1, fixed a bunch of relatively minor stuff but didn't do any of the things you are suggesting. These remain open as of now.
Jason,
On the server side, we have our own JSON parser which is really fast. We did some tests around that and it wasn't worth switching, our impl was significantly faster.
On the client side, we use Newtonsoft.Json by default, but also allow you to select your own serializer,you can use System.Text.Json is you want.
Bernhard ,
Actually, the other way around. A lot of our low level work was done while working with the JIT team. Some of our code was already in patterns that the 3.1 JIT knew better about, for example
@Ayende I meant this is what MS did in .NET Core 3.1.
You can also come to the conclusion that before .core 3.1 the .net stack under performed. Every iteration MS tries to get it better but it will never be native speed with manual memory disposing.
There is a reason that MS does not build their product with .net.
Edward,
It actually isn't that hard to get to native speed (or better) with .NET If you'll look at the TechEmpower benchmark, https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=plaintext you can see that asp.net core is within 0.2% of the top result (written in Rust). That is a damn impressive result
Edward,
It actually isn't that hard to get to native speed (or better) with .NET If you'll look at the TechEmpower benchmark, https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=plaintext you can see that asp.net core is within 0.2% of the top result (written in Rust). That is a damn impressive result
Comment preview