-
Notifications
You must be signed in to change notification settings - Fork 4.9k
Port perf changes and issues #41771
Port perf changes and issues #41771
Conversation
Question: How much effort would it be to port #40867 as well? Is none of the changes from that PR relevant anymore (it looks like that's the case)? I understand that the code changed since then, but it might be good to keep that history of changes in sync. That's the only PR tagged for perf not included here (6 of 7 targeted for 5.0 are): Also, were the commits here applied in the same order as they were checked-in to master? |
@@ -159,7 +159,8 @@ public static partial class JsonSerializer | |||
} | |||
} | |||
|
|||
writer.WritePropertyName(key); | |||
JsonEncodedText escapedKey = JsonEncodedText.Encode(key, options.Encoder); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an incorrect change. It is undoing the optimizations from #40991 (comment) / #41210
Please verify that nothing else from that PR is being changed, unintentionally. Also, how did this diff fall through?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Updated that and re-verified other commits.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, how did this diff fall through?
It didn't. That fix was done in an earlier change and was out-of-order and manually applied.
Yes |
d9e1ea7
to
e2da339
Compare
I did a manual diff between 5.0 and this PR and found this perf PR (#40114) that I just adorned with "performance" label. It has minor perf benefits, but is the only current 5.0 perf issue AFAIK not ported here. We should consider adding here (or in a subsequent PR). |
We can do in subsequent PR. I've reviewed all the commits and am OK with bringing them over to 3.1. We just need to document #40787. |
As far as I/tactics are concerned, this can be merged. BTW if someone accidentally squashes, I suggest reversing that commit and then doing it again so we have that nice history. I only mention this because I can totally imagine myself doing this 😄 |
// "encoder: null" is used since the literal values of "Key" and "Value" should not normally be escaped | ||
// unless a custom encoder is used that escapes these ASCII characters (rare). | ||
// Also by not specifying an encoder allows the values to be cached statically here. | ||
private static readonly JsonEncodedText _keyName = JsonEncodedText.Encode(KeyName, encoder: null); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Out of scope of this PR, but we should pass in the user-defined encoder for this (and not null). Though unlikely, if a user creates an encoder that escapes everything, then the payload would be incorrect.
The "No Merge" label is there to ensure when this is merged,the individual commits are NOT squashed (one commit here per original commit in master).
Peformance and three bug fixes:
Fixes #40449
Fixes #40704
Fixes #41425
On performance:
• Serialization is ~1.2x to ~1.5x faster than 3.0
• Deserialization is ~1.2x faster than 3.0
Ports the following: