Avoid overhead of constructing debug messages that are not printed #54
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 noticed that the neon pageserver unit tests were taking much longer with tokio-epoll-uring than with std:fs. It was because many of the tests used tokio::time:pause(), and then did a call to tokio::time::timeout() with a long 1h timeout. With tokio-epoll-uring, the loop in poller_impl_impl() woke up 36000 times, i.e. once for every 100 ms of virtual time, before the timeout was reached. The significance of that varies greatly depend on debug vs release build; it's particularly bad when I use nightly compiler with cranelift codegen backend.
It would be better to avoid the wakeups every 100 ms altogether, if the debug-level events are not enabled, but it scares me to have such different behavior depending on a debug-level. It sounds like a recipe for very hard-to-debug bugs. Or perhaps the debug dumping could be just removed altogether? That would be good for saving battery life when the system is idle.