Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Int Array lookup for PolymorphicFormatterResolver #42

Merged
merged 4 commits into from Feb 12, 2024

Conversation

to11mtm
Copy link
Member

@to11mtm to11mtm commented Feb 1, 2024

Changes

Use optimistic lookup Int Array instead of Concurrentdictionary for PolymorphicFormatterResolver.

No wire or format changes, internal only.

Checklist

For significant changes, please ensure that the following have been completed (delete if not relevant):

Benchmarks

I don't have numbers handy but this results in a >5% improvement in serialization benchmarks (due to lack of volatile reads or barriers on happy path and unsafe magic). Can produce receipts if needed. <3

Copy link
Member Author

@to11mtm to11mtm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added my own comments.

@@ -24,11 +24,12 @@ public sealed class MsgPackSerializer : Serializer
{
private readonly MsgPackSerializerSettings _settings;
private readonly IFormatterResolver _resolver;
public readonly MessagePackSerializerOptions _serializerOptions;
public readonly MessagePackSerializerOptions SerializerOptions;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's the polite thing to do for consumers that need to do some ugly things. :)


namespace Akka.Serialization.MessagePack.Resolvers
{
public class BackwardsCompatibleSurrogatedFormatterResolver : IFormatterResolver, IDoNotUsePolymorphicFormatter
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No changes here, just cleaned up and moved to it's own file.

Comment on lines +20 to +24
if (value == null)
{
writer.WriteNil();
}
else if (value.GetType() == typeof(T))
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This helps some optimizations and probably adds some needed safety (I do think Messagepack has it's own null protection but this helped perf since JITter knows .GetType() won't throw, and at best fixes a hazard I haven't seen previously.)

Semi related is that valuetype of default should be OK here, since null is not the same as default in generic context.

There may still be a better way to handle this (opt and more safety), open to suggestions!

private readonly object _lockObj = new();
public IntIndexedMessagePackFormatterDict(int initialSize)
{
_formatters = new IMessagePackFormatter[256];
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if a smaller size would be better here, I wanted to minimize re-allocs of the array but keep size 'fair'.

256 means it's gonna be 1Kib or 2Kib for the array to start.

//Should it happen, it just means we trust `TryAdd`
//which does a full fence and then checks state.
//Shouldn't happen much and only on startup...
var f = _formatters;
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Meant to leave a comment about 'capturing' the array here, OTOH I left enough exposition where hopefully context is provided?

@@ -121,7 +122,9 @@ public static IFormatterResolver LoadFormatterResolverByType(Type type, Extended
LoadFormatterResolverByType(t, system))
.Concat(new[]
{
#if SERIALIZATION
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IDK how these crept back in, I can remove?

@to11mtm to11mtm merged commit 899e7e5 into akkadotnet:dev Feb 12, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant