This repository has been archived by the owner on Nov 15, 2023. It is now read-only.
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.
polkadot companion: paritytech/polkadot#5393
This lowers the CPU overhead of our logging machinery when any
trace
log is enabled down to ~3% of what it is without anytrace
logs enabled.Background
The
tracing-log
crate has a bunch of relatively expensive filtering machinery which decides whether a given log should be printed out or not. This machinery has a fast path: if the current most verbose logging level is set to X then the logger can just reject every log which uses a more verbose level and skip the expensive checks.For example, if we have set
RUST_LOG
tofoo=info,bar=warn
then the most verbose log level isinfo
, so anytrace
logs can be quickly rejected because we know that a log must be at leastinfo
to be printable. Now, if we have setRUST_LOG
tofoo=info,bar=trace
then the most verbose log level istrace
, so now for anytrace
log the logger must actually check whether that log came fromfoo
or frombar
to decide whether it should be printed out, and this is expensive when you're generating thousands oftrace
logs every second (even if they're not printed out!).So this PR enables a built-in interest cache which I've previously added to
tracing-log
. This cache allows the logger to essentially skip the heavyweight filtering machinery by just doing the work once, and then just querying the cache on any subsequent call. According to the measurements I've done a long time ago this should cut down the CPU usage of the logger to ~3% when you have anytrace
log enabled (even if it's for a target which doesn't actually exist and will never actually match anything).(This is the second time I'm making this PR; the previous PR couldn't be merged since the
tracing-log
crate was not released on crates.io; but that finally changed today with the release oftracing-log
0.1.3.)