Improve JsonNumber performance

[kasiabulat]

JsonNumber uses string as a backing field, which requires unnecessarily expensive conversions.

Alternatives to consider:

• Span or array of Utf8String/Char8 (once they come online in the future) / byte
• Internal types that are specific to each numeric type in .NET with factories to create JsonNumber (Add spec for writable JSON DOM corefx#39954 (comment))
• Internal struct field which has all the supported numeric types
• Unsigned long field accompanying string to store types that are <= 8 bytes long (Writable Json DOM - JsonNumber implementation and tests corefx#39917 (comment))

Additionally, in JsonNumber.SetFormattedValue:

JsonWriterHelper.ValidateNumber(Encoding.UTF8.GetBytes(value).AsSpan());

unnecessarily allocates a byte[]. We can try and avoid that (and the solution depends on how perf critical this is).

• stackalloc the span for length < 256
• use array pool otherwise
• use the span-based overload of Encoding.UTF8.GetBytes on .NET Core (and char* overload on netfx) OR the helper in JsonWriterHelper.ToUtf8 similar to:
  https://github.com/dotnet/corefx/blob/97d5957fc71853961082e22873d926269b291b92/src/System.Text.Json/src/System/Text/Json/Writer/Utf8JsonWriter.WriteProperties.Helpers.cs#L207-L214

_Originally posted by @ahsonkhan in dotnet/corefx#39917 (comment) and dotnet/corefx#39917 (comment)

[ahsonkhan]

Originally posted by @ahsonkhan in https://github.com/_render_node/MDE3OlB1bGxSZXF1ZXN0UmV2aWV3MjY5MzU0MDgx/pull_request_reviews/more_threads

I don't think this link works (at least not for me).

[kasiabulat]

I don't think this link works (at least not for me).

I fixed the link.

[miloszkukla]

Which internal type would be chosen when parsing or converting from JsonElement? In Json.NET it is first parsed as int (or BigInt) and if it fails there is FloatParseHandling enum deciding whether to parse into float or decimal. Would there be something similar here?
For json writing in Json.NET there is also FloatFormatHandling enum worth mentioning.

Due to lack of recent activity, this issue has been marked as a candidate for backlog cleanup. It will be closed if no further activity occurs within 14 more days. Any new comment (by anyone, not necessarily the author) will undo this process.

This process is part of the experimental issue cleanup initiative we are currently trialing in a limited number of areas. Please share any feedback you might have in the linked issue.

[miloszkukla]

Comment just for a bot to not close the issue.

[eiriktsarpalis]

Closing, since the issue concerns an issue that was not eventually shipped (cf. #34099).