Details
-
Improvement
-
Resolution: Fixed
-
Major
-
None
-
None
-
None
-
3
-
SDK42
Description
Explanation
I'm profiling the C++ SDK on KV and transactions operations currently and seeing a few potential micro-optimisations that could be made. Take or leave these thoughts as you will I'll file them separately.
The source for the test app is here - note that only run_kv_lookup_in_workload is called, and that this workload simulates one of the reads that transactions do under-the-hood. The profiler is MSVC 2022.
"2% of TT" means 2% of the total CPU time as reported by the profiler. It's a sampling profiler using CPU clock not wallclock.
The issue
2% of TT is spent on the 3 add_tag lines here:
void send_to(io::mcbp_session session)
|
{
|
if (!handler_ || !span_) {
|
return;
|
}
|
session_ = std::move(session);
|
span_->add_tag(tracing::attributes::remote_socket, session_->remote_address());
|
span_->add_tag(tracing::attributes::local_socket, session_->local_address());
|
span_->add_tag(tracing::attributes::local_id, session_->id());
|
send();
|
}
|
|
This comes from a mix of fmt::format and threshold_logging_span::add_tag.
Similarly in map_and_send, 0.63% TT is spent on:
cmd->last_dispatched_from_ = session->local_address();
|
due to the fmt::format cost.
Suggestions
Suggestion 1: The Java SDK has an optimisation where if it's a basic span only created for ThresholdLogging purposes (where spans aren't used), it'll skip assigning tags.
Suggestion 2: Maybe the session's local and remote addresses can be cached?