Skip to content

Make HTTP request methods as const strings #12439

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

Conversation

cpp11nullptr
Copy link

Make HTTP request methods as const strings as it should never be changed.

@dnfclas
Copy link

dnfclas commented Jul 22, 2019

CLA assistant check
All CLA requirements met.

@Tratcher
Copy link
Member

Thanks for looking at this, but this behavior was intentional. Using statics allows us to use ReferenceEquals for quick equality checks. Consts get embedded in the calling code and no longer ref-equal.

@Tratcher Tratcher closed this Jul 22, 2019
@cpp11nullptr cpp11nullptr deleted the make-http-request-methods-as-const-strings branch July 22, 2019 14:57
analogrelay added a commit that referenced this pull request Jul 22, 2019
To help prevent well-meaning (but not actually desirable) changes like #12439
@analogrelay
Copy link
Contributor

Since there's nothing in the code to make it clear that this was intentional, I filed #12441 to add a comment describing this.

@cpp11nullptr
Copy link
Author

Thanks, @anurse.

@analogrelay
Copy link
Contributor

No problem! Without that additional context, your proposal to switch to const was entirely valid! Hopefully this helps clarify things.

@Pilchie
Copy link
Member

Pilchie commented Jul 22, 2019

I thought the runtime did ensure that string literals and constants were interned and ReferenceEqual except for a few corner cases involving things in generic types. Is that no longer the case?

@analogrelay
Copy link
Contributor

That does appear to be the case, I did some rough testing. There may be more complicated stuff at play though. I know @benaadams did some comparison of JIT-generated ASM when he made the change in HeaderNames (#9341) and saw a noticeable performance improvement from switching const to static readonly.

In general, I think we prefer to be specific here rather than rely on runtime behavior that we can't clearly assert.

@Pilchie
Copy link
Member

Pilchie commented Jul 22, 2019

In general, I think we prefer to be specific here rather than rely on runtime behavior that we can't clearly assert.

Definitely agree here.

@benaadams
Copy link
Member

benaadams commented Jul 22, 2019

I thought the runtime did ensure that string literals and constants were interned and ReferenceEqual except for a few corner cases involving things in generic types.

In the same assembly.

Public consts are compiled directly into the il of the referencing assembly if used in default parameters or attributes, so don't share the reference across assemblies.

The runtime can intern and dedupe across assembly but it doesn't do it aggressively (would cause start-up/jit perf impact) and a cross-assembly string const in a method body also prevents inlining https://github.com/dotnet/coreclr/issues/23969

Behind a static readonly field or method it uses a reference into the referenced assembly; and can inline everything happily and referenceequals is guaranteed to work without having to fallback to a char by char comparision.

@Pilchie
Copy link
Member

Pilchie commented Jul 22, 2019

In general, I think we prefer to be specific here rather than rely on runtime behavior that we can't clearly assert.

Ah, now I remember the issue. Thanks @benaadams! Glad we have a comment there now so people understand why the change was made.

analogrelay added a commit that referenced this pull request Jul 23, 2019
To help prevent well-meaning (but not actually desirable) changes like #12439
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.

6 participants