@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.Json now? 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.Json probably 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 )
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.
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.
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
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.
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
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
Comments have been closed on this topic.
Markdown formatting
ESC to close
Markdown turns plain text formatting into fancy HTML formatting.
Phrase Emphasis
*italic* **bold**
_italic_ __bold__
Links
Inline:
An [example](http://url.com/ "Title")
Reference-style labels (titles are optional):
An [example][id]. Then, anywhere
else in the doc, define the link:
[id]: http://example.com/ "Title"
> Email-style angle brackets
> are used for blockquotes.
> > And, they can be nested.
> #### Headers in blockquotes
>
> * You can quote a list.
> * Etc.
Horizontal Rules
Three or more dashes or asterisks:
---
* * *
- - - -
Manual Line Breaks
End a line with two or more spaces:
Roses are red,
Violets are blue.
Fenced Code Blocks
Code blocks delimited by 3 or more backticks or tildas:
```
This is a preformatted
code block
```
Header IDs
Set the id of headings with {#<id>} at end of heading line:
## My Heading {#myheading}
Tables
Fruit |Color
---------|----------
Apples |Red
Pears |Green
Bananas |Yellow
Definition Lists
Term 1
: Definition 1
Term 2
: Definition 2
Footnotes
Body text with a footnote [^1]
[^1]: Footnote text here
Abbreviations
MDD <- will have title
*[MDD]: MarkdownDeep
FUTURE POSTS
No future posts left, oh my!
RECENT SERIES
Challenge
(75): 01 Jul 2024 - Efficient snapshotable state
Recording
(14): 19 Jun 2024 - Building a Database Engine in C# & .NET
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.Json
now? 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.Json
probably 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