Cache buffers, allow omitting span names, options for not formatting KVs all the time#45
Draft
Cache buffers, allow omitting span names, options for not formatting KVs all the time#45
Conversation
This helps with the overhead of formatting the messages somewhat by not going out to the global allocator, though the impact is less than I had anticipated initially.
Tracy falls back to the function name in those instances, which for the `span!()` macro at least produces pretty reasonable results.
Owner
Author
|
I went ahead and merged the 2nd commit, since improving on it is difficult, others though… |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
With this plain
error!("banana")can take as little as 200ns (~0 overhead) but it will also lead to no meaningful messages if you haveerror!(someotherkey), and it will also drop all the KVs too.Similarly, emitting a span can happen in “just” 1.2µs which is also pretty nice.
Finally,
tracy_client::span!()“just works” and produces meaningful trace outputs, which is very nice. I think this one is likely uncontroversial and can be landed as is (see 2nd commit).Otherwise this is just a code/brain dump to which I don't anticipate returning for a foreseeable future. If somebody/anybody wants to finish this up somehow, I encourage you to do so ^^.