Use interned strings in Hub protocol implementations

[davidfowl]

Background and Motivation

Looking at profiles for one of my SignalR applications I see lots of string allocations showing up and most of them seem to come from the protocol implementation:

It's:

• Hub method names
• Invocation ids Not worth it unless we could optimize the number path and never allocate them.

We end up invoking these methods over and over and allocating the same strings for both invocation ids (numbers in our clients) and for hub method names (which are known at startup).

We should be using cached strings for these. Right now we don't have a clean extensibility model to inject this behavior. Maybe we can add something to the options.

Proposed API

namespace Microsoft.AspNetCore.SignalR;

public interface IInvocationBinder
{
+ #if NETCOREAPP
+    string? GetTarget(ReadOnlySpan<byte> utf8Bytes) => null;
+ #endif
}

Usage Examples

Called by SignalR protocols to get the cached hub name from the binder (if there exists any).

Alternative Designs

An alternative would be a new interface that can be optionally implemented on the IInvocationBinder:

public interface ITargetResolver
{
    string? GetTarget(ReadOnlySpan<byte> utf8Bytes);
}

Risks

None

Thanks for contacting us.

We're moving this issue to the .NET 7 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s).
If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues.
To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:

• The PR contains changes to the reference-assembly that describe the API change. Or, you have included a snippet of reference-assembly-style code that illustrates the API change.
• The PR describes the impact to users, both positive (useful new APIs) and negative (breaking changes).
• Someone is assigned to "champion" this change in the meeting, and they understand the impact and design of the change.

[halter73]

API Review Notes:

• Why cross compile? DIMs.
• Do we like a new interface to support netstandard2.0? No, it's hard to discover and perf-sensitive libs should cross-compile.

Approved as proposed:

public interface IInvocationBinder
{
+ #if NETCOREAPP
+    string? GetTarget(ReadOnlySpan<byte> utf8Bytes) => null;
+ #endif
}