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

README.md: avoid []byte -> string allocation/copy #98

Merged
merged 1 commit into from
Mar 27, 2021
Merged

README.md: avoid []byte -> string allocation/copy #98

merged 1 commit into from
Mar 27, 2021

Conversation

extemporalgenome
Copy link
Contributor

FreeCache invests a lot of effort to minimize GC overhead, yet the README example has a case where a (potentially very large) copy is made just as part of a fmt.Println call. With this change, it uses fmt.Printf("%s\n", ...), which should be used in any case involving Println and a []byte that's intended to be interpreted as string data.

FreeCache invests a lot of effort to minimize GC overhead, yet the README example has a case where a (potentially very large) copy is made just as part of a `fmt.Println` call. With this change, it uses `fmt.Printf("%s\n", ...)`, which should be used in any case involving `Println` and a `[]byte` that's intended to be interpreted as string data.
@coocood
Copy link
Owner

coocood commented Mar 27, 2021

Good suggestion, Thank you!

@coocood coocood merged commit 6e76df7 into coocood:master Mar 27, 2021
SilverHL pushed a commit to SilverHL/freecache that referenced this pull request Sep 27, 2021
FreeCache invests a lot of effort to minimize GC overhead, yet the README example has a case where a (potentially very large) copy is made just as part of a `fmt.Println` call. With this change, it uses `fmt.Printf("%s\n", ...)`, which should be used in any case involving `Println` and a `[]byte` that's intended to be interpreted as string data.

Change-Id: I01e6067e3c2da12dfd75e391728265b749b848ca
SilverHL pushed a commit to SilverHL/freecache that referenced this pull request Sep 27, 2021
FreeCache invests a lot of effort to minimize GC overhead, yet the README example has a case where a (potentially very large) copy is made just as part of a `fmt.Println` call. With this change, it uses `fmt.Printf("%s\n", ...)`, which should be used in any case involving `Println` and a `[]byte` that's intended to be interpreted as string data.

Change-Id: I01e6067e3c2da12dfd75e391728265b749b848ca
SilverHL pushed a commit to SilverHL/freecache that referenced this pull request Sep 27, 2021
FreeCache invests a lot of effort to minimize GC overhead, yet the README example has a case where a (potentially very large) copy is made just as part of a `fmt.Println` call. With this change, it uses `fmt.Printf("%s\n", ...)`, which should be used in any case involving `Println` and a `[]byte` that's intended to be interpreted as string data.

Change-Id: I01e6067e3c2da12dfd75e391728265b749b848ca
SilverHL pushed a commit to SilverHL/freecache that referenced this pull request Sep 27, 2021
FreeCache invests a lot of effort to minimize GC overhead, yet the README example has a case where a (potentially very large) copy is made just as part of a `fmt.Println` call. With this change, it uses `fmt.Printf("%s\n", ...)`, which should be used in any case involving `Println` and a `[]byte` that's intended to be interpreted as string data.

Change-Id: I01e6067e3c2da12dfd75e391728265b749b848ca
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.

2 participants