Adding lazy logging along critical path #343
Merged
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.
Description
f-strings
are evaluated before passing them down to the logging functions (even if they are not used). By using boring (and IMO harder to read)%s
or%r
we can delay or elude that work depending on the logging settings.With debug level logging disabled, this won't necessarily save a noticeable amount of run time on one individual run but will save CPU cycles none the less.
This also does not change all the instances of passing
f-strings
to logging functions. My goal was only to change the ones that would have the biggest impact (i.e. evaluatingf"read: {buf!r}"
everyread
even with debug logging disabled)Type of change
Please delete options that are not relevant.
How Has This Been Tested?
I've run a handful of scripts with and without logging enabled and everything seems to be working the same. I've used
py-spy
to approximate that there is less work happening with debugging disabled.Checklist:
make lint
beforecommitting!)
docstrings include a summary, args, returns and raises fields (even if N/A)
note if there are any considerations for the vrnetlab setup