-
Notifications
You must be signed in to change notification settings - Fork 18k
time: optimize Parse and Time.Format for RFC3339 #54093
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
Comments
Is it appropriate to offer my contribution here? |
Sure, your contribution is welcomed. See https://go.dev/doc/contribute for how to contribute to Go. Thanks. |
Happy to review. |
Sure. I’ll be back shortly with initial implementation. |
Change https://go.dev/cl/421877 mentions this issue: |
Change https://go.dev/cl/425100 mentions this issue: |
Change https://go.dev/cl/425197 mentions this issue: |
Time.appendFormatRFC3339 is a specialized implementation of Time.appendFormat. We expect the two to be identical. Add a fuzz test to ensure this property. Updates #54093 Change-Id: I0bc41ee6e016d3dac75d1ac372d8c9c7266d0299 Reviewed-on: https://go-review.googlesource.com/c/go/+/425100 Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Heschi Kreinick <heschi@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com>
RFC 3339 is the most common time representation, being used in an overwhelming 57.3% of all specified formats, while the next competitor only holds 7.5% usage. Specially optimize parsing to handle the RFC 3339 format. To reduce the complexity of error checking, parseRFC3339 simply returns a bool indicating parsing success. It leaves error handling to the general parse path. To assist in fuzzing, the internal parse function was left unmodified so that we could test that parseRFC3339 and parse agree with each other. Performance: name old time/op new time/op delta ParseRFC3339UTC 112ns ± 1% 37ns ± 1% -67.37% (p=0.000 n=9+9) ParseRFC3339TZ 259ns ± 2% 67ns ± 1% -73.92% (p=0.000 n=10+9) Credit goes to Amarjeet Anand for a prior CL attemping to optimize this. See CL 425014. Fixes #54093 Change-Id: I14f4e8c52b092d44ceef6863f261842ed7e83f4c Reviewed-on: https://go-review.googlesource.com/c/go/+/425197 Reviewed-by: Rob Pike <r@golang.org> Run-TryBot: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Joseph Tsai <joetsai@digital-static.net> Reviewed-by: Jenny Rakoczy <jenny@golang.org>
RFC3339 is the most common format to use (according to prior analysis, it accounts for 57% of formats; and that's only explicit calls to
Format
orParse
. It doesn't cover all the implicit cases that occur throughMarshalText
andUnmarshalText
). We should optimizeParse
andTime.Format
to do a quick check for theRFC3339Nano
orRFC3339
constants and hardcode the logic for that format. This would avoid the double parsing that currently occurs where we parse the format string to functionally run a virtual machine that then parses the input value.The text was updated successfully, but these errors were encountered: