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

some optimization direction when use []byte ,string ,fmt.Spintf. #893

Closed
liu-song opened this issue Nov 13, 2021 · 0 comments
Closed

some optimization direction when use []byte ,string ,fmt.Spintf. #893

liu-song opened this issue Nov 13, 2021 · 0 comments

Comments

@liu-song
Copy link
Contributor

liu-song commented Nov 13, 2021

Is your feature request related to a problem? Please describe.
Not a problem,just some optimization.

Describe the solution you'd like
when we transform []byte to string or string to []byte, below way will more faster:

func b2s(b []byte) string {
	return *(*string)(unsafe.Pointer(&b))
}
func s2b(s string) (b []byte) {
	bh := (*reflect.SliceHeader)(unsafe.Pointer(&b))
	sh := (*reflect.StringHeader)(unsafe.Pointer(&s))
	bh.Data = sh.Data
	bh.Cap = sh.Len
	bh.Len = sh.Len
	return b
}

the function is Copied from fasthttp ,https://github.com/valyala/fasthttp/blob/master/bytesconv.go#L333 , which also is used in gin https://github.com/gin-gonic/gin/blob/master/internal/bytesconv/bytesconv.go#L12 and so on .

when we use the function fmt.Spintf to concatenated string #891,it will case more because use interface ,reflect , append . it is more suitable to use strings.Builder or bytes.Buffer .

In the bfe can make some performances improvement in these cases.

Describe alternatives you've considered
when we use b2s or s2b ,it also need pay more attention because unsafe . fasthttp has some discussion on this case;
valyala/fasthttp#1031
valyala/fasthttp#1151

Additional context
Add any other context or screenshots about the feature request here.

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

No branches or pull requests

1 participant