GODEBUG flags

[Dave Cheney]

Hello,

I've seen comments raised by Dmitry [1] about debugging flags adding
runtime overhead, and favouring enums that can be switched at compile
time rather than branches in the hot path at run time.

I'm torn on this issue because while I do love things to be fast, I
think serviceability of the Go runtime is an issue which needs more
attention and having these options compiled out makes it harder for
people to solve their own problems, especially as Go is starting to
make some inroads in being packaged in the major OS distributions.

While I suspect it won't be popular, I'd like to propose a single
release/debug flag which gates these new GODEBUG options. The builders
would always build in debug mode, and probably the builds released
from the release branch would build in release mode.

Thoughts ?

Cheers

Dave

[1] https://codereview.appspot.com/21990045/ and others

[Dmitry Vyukov]

Probably we can come up with some scheme that combines the new debug branches with some existing slow-path branch:

if(...) {

  // various slow-paths and debug things

  if(...)

    ...

  if(...)

    ...

  if(...)

    ...

}

[Ingo Oeser]

Isn't it simply "GODEBUG environment variable is set at all" ?

[Russ Cox]

I think you (and Dmitriy) are overestimating the slowdown due to checking a global int that never changes. There may be one or two places in the whole runtime where the check would actually influence performance. Those can be handled specially (perhaps by having a fast and slow path as Dmitriy wrote), once they are identified as such. Until you have profiles showing that the debug variables are causing significant slowdown, I wouldn't worry about them.

Russ