How much runtime perf overhead we can expect with tracing spans without subscribers?

[kwonoj]

Context: I'm working on SWC (https://github.com/swc-project/swc) to enable tracing support. I've added initial spans via #[instrument] macro with few manual spans - can be found at https://github.com/swc-project/swc/pull/3911/files - and it seems like creating non-negligible runtime overhead on some local number comparison between current TOT of master : swc-project/swc#3911 (comment)

PR:

test full_es2015                  ... bench:  80,136,808 ns/iter (+/- 7,580,107)
test full_es2016                  ... bench:  85,148,904 ns/iter (+/- 30,743,348)
test full_es2017                  ... bench:  87,605,962 ns/iter (+/- 16,405,189)
test full_es2018                  ... bench:  84,212,345 ns/iter (+/- 13,840,869)
test full_es2019                  ... bench:  85,074,516 ns/iter (+/- 12,216,482)
test full_es2020                  ... bench:  80,233,583 ns/iter (+/- 14,899,070)
test full_es3                     ... bench: 111,405,208 ns/iter (+/- 10,115,031)
test full_es5                     ... bench: 103,204,875 ns/iter (+/- 9,714,975)
test parser                       ... bench:     246,809 ns/iter (+/- 8,527)
Main:

test full_es2015                  ... bench:  62,123,141 ns/iter (+/- 5,155,507)
test full_es2016                  ... bench:  61,233,145 ns/iter (+/- 6,222,669)
test full_es2017                  ... bench:  61,224,904 ns/iter (+/- 6,650,323)
test full_es2018                  ... bench:  60,357,304 ns/iter (+/- 4,089,180)
test full_es2019                  ... bench:  60,029,079 ns/iter (+/- 4,770,494)
test full_es2020                  ... bench:  57,809,924 ns/iter (+/- 4,155,606)
test full_es3                     ... bench:  81,534,441 ns/iter (+/- 4,828,373)
test full_es5                     ... bench:  76,303,150 ns/iter (+/- 4,709,092)
test parser                       ... bench:     246,544 ns/iter (+/- 3,130)

Roughly, number may vary but worst cast > 20%. In the test above, test parser is a base we can sure those 2 sets ran under similar considiton as parser does not have any tracing at the moment.

I was under assumption having span will create some runtime overhead but it's generally within acceptable threshold unless there's actual subscriber is running. All of those results are coming from test set doesn't have any subscribers though. There maybe following q, as an initial question

• Is it expected overhead to have spans & traces without subscribers?
• If not, what's expected numbers in general?
• If not, did I make some mistakes in current PR have to be fixed? (https://github.com/swc-project/swc/pull/3911/files) among those PR changes, there's #[swc_trace] macro which appends #[instrument] for the fn for specific impl. (https://github.com/swc-project/swc/blob/main/crates%2Fswc_trace_macro%2Fsrc%2Flib.rs#L19)

Thanks! 🙏

[davidbarsky]

I think it was more than it needed to be! @hawkw just landed a PR (#1974) that reduced the overhead of spans without subscribers between 50-70%.

To answer questions:

Is it expected overhead to have spans & traces without subscribers?

Yes, there's some overhead in that case. The compile-time filters might help reduce overhead, though.

If not, what's expected numbers in general?

I'm not entirely sure. I'll defer to Eliza on that point.

If not, did I make some mistakes in current PR have to be fixed?

I'll take a look!