Logging a span without allocating

[sujayakar]

Hello! I was profiling a very performance sensitive app, and I wanted to get tracing overhead as low as possible. The implementation of Span calls ___tracy_alloc_strloc_name and ___tracy_emit_zone_begin_alloc_callstack, which were too expensive for my usecase.

In my fork (https://github.com/sujayakar/rust_tracy_client), I've added a static_span! macro that avoids dynamic allocation by using &'static strs for the function name and file name. The implementation (https://github.com/sujayakar/rust_tracy_client/blob/main/tracy-client/src/lib.rs#L67) uses some pretty gnarly nightly features. Would you be interested in my upstreaming this?

[nagisa]

I would not mind something like this all that much. From my perspective tracy-client is significantly less important to get “right” from the get-go. There isn't really anything that prevents me from making breaking changes to it in the future if we end up finding a better solution.

Perhaps most disappointing to me is that this doesn't help with fixing a similar problem in tracing-tracy which I consider much more important crate personally. I recently also fiddled with a similar issue for that crate specifically, but sadly allocations still cannot be removed entirely there – at least one allocation per span will be required (due to the use of null-terminated strings.).

uses some pretty gnarly nightly features

From a quick look, I would say that these features are avoidable; at least if we are fine with falling back to populating the function name field with a module!() instead. And we could add a nightly feature for the nightly implementation…

[Ralith]

I'd love to see the regular span! macro not allocate, and I'd be willing to sacrifice function names for that if necessary--but maybe we could just build them up in a stack buffer and truncate unreasonable large ones?

[nagisa]

Nope, I believe that Tracy requires a 'static data structure here.

[Ralith]

Another option would be to stash the formatted data inside a OnceCell in a static. This adds a dep, but it's a very common one that's expected to eventually migrate into std.

[nagisa]

This has been added in #33