Replies: 2 comments 3 replies
-
|
@steabert Hi, thanks for reaching out. We did a quick test with a package main
import (
"fmt"
"net/http"
"github.com/DataDog/dd-trace-go/v2/ddtrace/tracer"
httptrace "github.com/DataDog/dd-trace-go/contrib/net/http/v2"
)
func main() {
tracer.Start()
defer tracer.Stop()
mux := httptrace.NewServeMux()
mux.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hello world!")
})
http.ListenAndServe(":3000", nil)
}This is the breakdown as generated by
Regarding |
Beta Was this translation helpful? Give feedback.
-
|
We did some efforts this quarter, and found new venues to further reduce it. We've removed unmaintained dependencies and documented the usage of known build tags that can yield more than 5% reduction. |
Beta Was this translation helpful? Give feedback.

Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi!
I'm trying to move from using OpenTelemetry (via
go.opentelemetry.io/otel/trace) for custom tracing to usingdd-trace-go/v2/ddtrace/tracerin my application (a server which runs in a kubernetes cluster with a datadog agent present).Unfortunately, the executable size increases by ~9MB compared to using the otel libraries. This seems unreasonable for a library which is supposed to create some spans and send them off to the agent. Trying to look into it myself I found that part of the issue was that it pulls in gogo/protobuf, so I assume that's used as a wire format for agent communication, fair enough. However that cannot account for the entire size.
Does anyone know why this library increases executable size by ~9MB ?
Beta Was this translation helpful? Give feedback.
All reactions