Skip to content

Minor optimization to avoid using BigInteger if possible #1016

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

Merged
merged 2 commits into from
Sep 27, 2019

Conversation

tylerbenson
Copy link
Contributor

No description provided.

@tylerbenson tylerbenson requested a review from a team as a code owner September 27, 2019 17:27
Copy link
Contributor

@dougqh dougqh left a comment

Choose a reason for hiding this comment

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

If we can use JsonGenerator::writeNumber(String), I think that would be better.
If not, it would be good to have a microbenchmark to quantify the gain.

@@ -430,7 +431,15 @@ public UInt64IDStringSerializer(final Class<String> stringClass) {
public void serialize(
final String value, final JsonGenerator gen, final SerializerProvider provider)
throws IOException {
gen.writeNumber(new BigInteger(value));
final int length = value.length();
// BigInteger's are expensive, so lets try to avoid using them if possible.
Copy link
Contributor

Choose a reason for hiding this comment

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

Can we use JsonGenerator::writeNumber(String)?
The doc says it isn't support for all generators, but if it is available it would save us parsing & allocating.

My other thought was a custom Number class to represent UInt64, but JsonGenerator doesn't support that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, fair enough. I was hoping that it would be implemented more efficiently, but apparently, it is less efficient.

@tylerbenson tylerbenson merged commit 91cbb67 into master Sep 27, 2019
@tylerbenson tylerbenson deleted the tyler/parse-optimization branch September 27, 2019 22:24
@tylerbenson tylerbenson added this to the 0.34.0 milestone Oct 11, 2019
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.

2 participants