perf: higher performance unsafeStringToSlice

[dxasu]

Higher performance UnsafeStringToSlice

What type of PR is this?

perf

Check the PR title.

• [x] This PR title match the format: \<type>(optional scope): \<description>
• [x] The description of this PR title is user-oriented and clear enough for others to understand.
• [x] Attach the PR updating the user documentation if the current PR requires user awareness at the usage level. User docs repo

(Optional) More detailed description for this PR(en: English/zh: Chinese).

en: higher performance unsafeStringToSlice

(Optional) Which issue(s) this PR fixes:

Fixes #370

[xiaost]

Benchmark? Comparison? Also the assumption of the structure size which equals to []byte is unacceptable.

[joway]

@xiaost https://github.com/cloudwego/netpoll/issues/370 it just reduce the MOVQ instruction times. the assumption is sliceHeader and stringHeader should not change in the future.

[xiaost]

@joway it can be different size for string and stringheader. reflect.StringHeader will not be changed, but it doesn't mean string can not add more fields to the end of reflect.StringHeader.

[xiaost]

func UnsafeStringToSlice(s string) (b []byte) {
    *(*string)(unsafe.Pointer(&b)) = s
    (*reflect.SliceHeader)(unsafe.Pointer(&b)).Cap = len(s)
    return
}

try this code snippet which has better readability if we'd like to sacrifice forward compatibility for the minor optimisation.

I won't do that.

[dxasu]

@xiaost In go1.20, that reflect.StringHeader and reflect.SliceHeader are [officially deprecated]

func UnsafeStringToSlice(s string) []byte {
    return unsafe.Slice(unsafe.StringData(s), len(s))
}

[xiaost]

@dxasu I know what you said, but I don't know what is your point.