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.

Sign up for GitHub

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

Jump to bottom

optimize parsing ulid #116

Open
wants to merge 5 commits into
base: main
Choose a base branch
from
Open

optimize parsing ulid #116

wants to merge 5 commits into from

Conversation

shogo82148
Copy link
Contributor

@shogo82148 shogo82148 commented Mar 4, 2024 •
edited
Loading

In this pull request, we have improved the performance of Parse. Instead of directly converting ULID to a [16]byte, it is converted through multiple uint64 variables. This change allows us to reduce the number of bit operations, leading to faster performance.

The result of benchmark is here:

goos: darwin
goarch: arm64
pkg: github.com/oklog/ulid/v2
               │   .old.txt   │              .new.txt               │
               │    sec/op    │   sec/op     vs base                │
Parse-10          9.158n ± 1%   6.051n ± 1%  -33.92% (p=0.000 n=10)
ParseStrict-10   14.515n ± 1%   6.106n ± 1%  -57.94% (p=0.000 n=10)
MustParse-10     10.095n ± 0%   7.076n ± 0%  -29.91% (p=0.000 n=10)
geomean           11.03n        6.394n       -42.03%

               │   .old.txt   │               .new.txt                │
               │     B/s      │     B/s       vs base                 │
Parse-10         2.644Gi ± 1%   4.002Gi ± 1%   +51.35% (p=0.000 n=10)
ParseStrict-10   1.668Gi ± 1%   3.966Gi ± 1%  +137.79% (p=0.000 n=10)
MustParse-10     2.399Gi ± 0%   3.422Gi ± 0%   +42.64% (p=0.000 n=10)
geomean          2.195Gi        3.787Gi        +72.51%

               │   .old.txt   │              .new.txt               │
               │     B/op     │    B/op     vs base                 │
Parse-10         0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=10) ¹
ParseStrict-10   0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=10) ¹
MustParse-10     0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=10) ¹
geomean                     ²               +0.00%                ²
¹ all samples are equal
² summaries must be >0 to compute geomean

               │   .old.txt   │              .new.txt               │
               │  allocs/op   │ allocs/op   vs base                 │
Parse-10         0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=10) ¹
ParseStrict-10   0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=10) ¹
MustParse-10     0.000 ± 0%     0.000 ± 0%       ~ (p=1.000 n=10) ¹
geomean                     ²               +0.00%                ²
¹ all samples are equal
² summaries must be >0 to compute geomean

peterbourgon
peterbourgon reviewed Mar 13, 2024
View reviewed changes
ulid.go Outdated Show resolved Hide resolved
peterbourgon
peterbourgon reviewed Mar 13, 2024
View reviewed changes
ulid.go Outdated Show resolved Hide resolved
peterbourgon
peterbourgon reviewed Mar 13, 2024
View reviewed changes
ulid.go Show resolved Hide resolved
@peterbourgon
Copy link
Member

I've misunderstood something here, let me revert.

@shogo82148
Copy link
Contributor Author

This code relies on the behavior of sign extension. Therefore, dec must be a negative number.

@peterbourgon
Copy link
Member

Please look at this PR from the perspective of a future maintainer. Help them understand how this works, and why it's better than the previous approach, with documentation.

@peterbourgon peterbourgon mentioned this pull request Apr 7, 2024
Open
@shogo82148
Copy link
Contributor Author

I updated the description of the pull request, and comments in the source.
Can you take a look please?

@shogo82148 shogo82148 mentioned this pull request Apr 7, 2024
Open
@oderwat
Copy link

oderwat commented Apr 15, 2024

@peterbourgon I would even be happy to have better performance in my downstream applications, even if I do not understand all the bit juggling. Just saying.

@peterbourgon
Copy link
Member

Of course, but when this code is merged, it becomes my responsibility, so I need to understand it, even if you don't :)

@oderwat
Copy link

oderwat commented Apr 15, 2024

@peterbourgon I see. Thank you for this very nice package. I hope you will find the time to understand what he did soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@peterbourgon peterbourgon peterbourgon left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@shogo82148 @peterbourgon @oderwat