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

Optimize Timestamp Formatting #15039

Merged
merged 1 commit into from
Nov 16, 2022

Conversation

pettyjamesm
Copy link
Member

Description

Optimize SqlTimestamp and SqlTimestampWithTimeZone string formatting by calculating the exact required buffer size and avoiding a call to String.format("%0" + precision + "d", ...) on a per-row basis.

Non-technical explanation

No non-technical explanation should be necessary since this is an internal implementation detail.

Release notes

(x) This is not user-visible or docs only and no release notes are required.
( ) Release notes are required, please propose a release note for me.
( ) Release notes are required, with the following suggested text:

@cla-bot cla-bot bot added the cla-signed label Nov 15, 2022
@pettyjamesm pettyjamesm force-pushed the optimize-timestamp-to-string branch 2 times, most recently from 2a2deb4 to a608d08 Compare November 15, 2022 21:24
Compute exact size StringBuilders and avoid using String.format
to produce timestamp string representations.
// comparable to format("%0" + precision + "d", scaledFraction);
for (int i = 0; i < precision; i++) {
long temp = scaledFraction / 10;
int digit = (int) (scaledFraction - (temp * 10));
Copy link
Member

Choose a reason for hiding this comment

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

Why not scaledFraction % 10 ? Is there a measurable performance difference?

Copy link
Member Author

Choose a reason for hiding this comment

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

I didn't specifically measure it, this is a variation on the logic inside of Long.toString so I presume it was implemented that way on purpose.

(Long.toString resolves two decimal digits per iteration and therefore also uses lookup tables to convert to char instead of (char)('0' + digit), but that was definitely overkill for this scenario).

@martint martint merged commit 798474b into trinodb:master Nov 16, 2022
@pettyjamesm pettyjamesm deleted the optimize-timestamp-to-string branch November 16, 2022 17:57
@github-actions github-actions bot added this to the 404 milestone Nov 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

2 participants