Will go compiler do optimization here if "bytes" is a global variable?

248 views
Skip to first unread message

T L

unread,
Jul 23, 2016, 3:03:03 PM7/23/16
to golang-nuts
http://go-talks.appspot.com/github.com/davecheney/presentations/writing-high-performance-go.slide#30

the above slide says "the conversion of the byte slice to a string" in the following case will no copy the underlining byte array.
 
var m = map[string]string{}
v, ok := m[string(bytes)]

If "bytes" is a local variable, it is reasonable the compiler will do the optimization.
But how about if "bytes" is a global variable?

Jan Mercl

unread,
Jul 23, 2016, 3:09:40 PM7/23/16
to T L, golang-nuts
On Sat, Jul 23, 2016 at 9:03 PM T L <tapi...@gmail.com> wrote:

> If "bytes" is a local variable, it is reasonable the compiler will do the optimization.
> But how about if "bytes" is a global variable?

Not sure what a global variable is. Go has universe scope, but user code cannot declare variables in that scope. Assuming a package scope is meant instead: such optimization might be possible Iff the compiler is able to prove that no one is ever mutating the slice.

--

-j

Axel Wagner

unread,
Jul 23, 2016, 3:22:39 PM7/23/16
to Jan Mercl, T L, golang-nuts
The answer, I think, is yes. Because the only way, that any modification of bytes can occur, is if there's a race and in the case of a race (hehe) all bets are off anyway. I also see no reason for the scope of bytes to have any influence on it, as races can also occur with variables in local scope. If anything, escape analysis might.

But to get a definite answer just try it out. Write the code, throw in some concurrent modifications of bytes just for good measure (so the compiler can't prove that no modification occurs) and look at the generated code.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Keith Randall

unread,
Jul 23, 2016, 10:56:35 PM7/23/16
to golang-nuts, 0xj...@gmail.com, tapi...@gmail.com
This was a concern when we originally implemented the m[string(b)] optimization.  If someone is simultaneously modifying b, then weird things happen during the lookup.  But it won't crash anything, just maybe not return what you expect.  And that's ok in cases of a data race, the spec makes no promises.

T L

unread,
Jul 25, 2016, 11:37:03 AM7/25/16
to golang-nuts
@Randall, thanks for answer.
You mean the answer is yes, right?

Keith Randall

unread,
Jul 25, 2016, 8:32:21 PM7/25/16
to golang-nuts
Yes, it is.  The optimization occurs for any occurrence of m[string(expression of type []byte)].  Where the byte slice came from (global or otherwise) is irrelevant.
Reply all
Reply to author
Forward
0 new messages