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

proposal: bytes: separate the package bytes into the Unicode-related part and the others #40782

Closed
hajimehoshi opened this issue Aug 14, 2020 · 5 comments

Comments

@hajimehoshi
Copy link
Member

hajimehoshi commented Aug 14, 2020

The problem of unicode is that this tends to bloat the binary size [1]. Now the package bytes imports the package unicode. Even if you want to use just byte.Buffer, you have to import unicode indirectly, which is unfortunate. Would it be possible to separate bytes package into APIs that are related to Unicode and the others, probably in Go2?

[1] For example: hajimehoshi/ebiten#1157 (comment): unicode.init takes 22359 bytes IIUC

@gopherbot gopherbot added this to the Proposal milestone Aug 14, 2020
@davecheney
Copy link
Contributor

@hajimehoshi could you bisect to figure out when the dependency between bytes and unicode was added. Thank you.

@hajimehoshi
Copy link
Member Author

2f5e758 before Go1.0?

@davecheney
Copy link
Contributor

Thanks for confirming.

@martisch
Copy link
Contributor

If the goal is to reduce binary size then I dont think just splitting bytes is worth the churn in either Go 1 or Go 2.

Many other packages strings, fmt, reflect will still require unicode to be imported making the number of go programs after the split not importing Unicode very small still.

The ergonomics when programming of having to reason in which package to find the corresponding bytes function that previously were all together in one package is I think not worth the 22k byte saved.

To tackle this problem for all packages I think (apart from avoiding adding unicode dependencies were possible) is to work on compiler and linker optimisations making the imported parts of unicode smaller. e.g. #38784
This also has the advantage of not requiring Go 2 incompatibilities.

@hajimehoshi
Copy link
Member Author

Many other packages strings, fmt, reflect will still require unicode to be imported making the number of go programs after the split not importing Unicode very small still.

Fair enough. Focusing on reducing the binary size of unicode itself makes much more sense.

@golang golang locked and limited conversation to collaborators Aug 14, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants