New client option DisableLogStderr
to disable expensive log stderr from subprocess
#316
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I have a light weighted go-plugin client that talks to a terraform provider, mainly to import and read one or more terraform resources from the provider.
I expect this is anI/O bound task, instead of CPU intensive, as the client&provider will be waiting for the cloud platform API call in most of the time. However, the result turns out the CPU is also non-negligible.
The provider I'm talking to is the
terraform-provider-azurerm
, whose on initialization is a bit wordy that will print a bunch of logs. By doing some benchmark and profiling. I noticed that the go routine for logging stderr from the subprocess is consuming about 20% of the CPU time:With this PR to disable the log stderr, especially the expensive
parseJSON
, we can get 20% performance improvement:Ideally, we shall check whether the
logger
is ahclog.NullLogger
and theconfig.Stderr
isio.Discard
, instead of introducing this new property. While I don't know if there is a way to do the first check (as the current default behaivor for nullconfig.Logger
is to set a logger to set a non-noop logger.Also note that when this
DisableLogStderr
won't stop spawning the go routine at all since we still need to check whether the stderr hit EOF to tell whether the subprocess has ended.