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

Two encoding-related cleanups #82

Merged
merged 2 commits into from
Jun 23, 2023
Merged

Two encoding-related cleanups #82

merged 2 commits into from
Jun 23, 2023

Conversation

danmcgee-soda
Copy link
Contributor

Remove superfluous bitmasking in encode

We only need to mask with &0x1F once per generated character, rather
than twice as we did in many cases. As long as the &0x1F operation is
last, we will always throw away the top three bits as expected.

Remove use of unsafe in String() method

Now that an Encode() method was added in #56, it is less necessary to
resort to unsafe methods in String(). This also appears to have
minimal benefit, as seen by these before (using unsafe) and after
(without unsafe) benchmarks:

Before (using unsafe):

% go test -benchmem -bench .
goos: darwin
goarch: arm64
pkg: github.com/rs/xid
BenchmarkNew-8          	21845306	        52.34 ns/op	       0 B/op	       0 allocs/op
BenchmarkNewString-8    	22674129	        51.18 ns/op	       0 B/op	       0 allocs/op
BenchmarkFromString-8   	286217863	         4.233 ns/op	       0 B/op	       0 allocs/op
PASS
ok  	github.com/rs/xid	4.142s

After (without unsafe):

% go test -benchmem -bench .
goos: darwin
goarch: arm64
pkg: github.com/rs/xid
BenchmarkNew-8          	21423278	        53.01 ns/op	       0 B/op	       0 allocs/op
BenchmarkNewString-8    	21977233	        53.67 ns/op	       0 B/op	       0 allocs/op
BenchmarkFromString-8   	289641164	         4.162 ns/op	       0 B/op	       0 allocs/op
PASS
ok  	github.com/rs/xid	4.181s

There is very little speed difference between the two.

We only need to mask with `&0x1F` once per generated character, rather
than twice as we did in many cases. As long as the `&0x1F` operation is
last, we will always throw away the top three bits as expected.
Now that an `Encode()` method was added in rs#56, it is less necessary to
resort to unsafe methods in `String()`. This also appears to have
minimal benefit, as seen by these before (using unsafe) and after
(without unsafe) benchmarks:

Before (using unsafe):

% go test -benchmem -bench .
goos: darwin
goarch: arm64
pkg: github.com/rs/xid
BenchmarkNew-8          	21845306	        52.34 ns/op	       0 B/op	       0 allocs/op
BenchmarkNewString-8    	22674129	        51.18 ns/op	       0 B/op	       0 allocs/op
BenchmarkFromString-8   	286217863	         4.233 ns/op	       0 B/op	       0 allocs/op
PASS
ok  	github.com/rs/xid	4.142s

After (without unsafe):

% go test -benchmem -bench .
goos: darwin
goarch: arm64
pkg: github.com/rs/xid
BenchmarkNew-8          	21423278	        53.01 ns/op	       0 B/op	       0 allocs/op
BenchmarkNewString-8    	21977233	        53.67 ns/op	       0 B/op	       0 allocs/op
BenchmarkFromString-8   	289641164	         4.162 ns/op	       0 B/op	       0 allocs/op
PASS
ok  	github.com/rs/xid	4.181s
@danmcgee-soda
Copy link
Contributor Author

Anything I can do here to get this looked at?

@rs rs merged commit 08be0c9 into rs:master Jun 23, 2023
@danmcgee-soda danmcgee-soda deleted the encode-cleanups branch July 10, 2023 14:12
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.

None yet

2 participants