Custom Memory Allocation Support

[matgrioni]

Hi Open Telemetry team,

I've been studying the code in this repo to understand the design of library components for such systems. One thing that stands out to me is the lack of custom allocator support with everything defaulting to std::allocator (at least from what I have seen, perhaps I missed something).

I was just curious on the thought process and discussions here, since it seems like a drawback for certain applications. For high(er) performance or throughput server applications, std::allocator is infeasible to use on the live path of request processing, and so this library as is cannot be incorporated. Given highly templated nature of implementations supporting custom memory allocation, it also seems like a difficult decision to walk back on without other significant design considerations.

[ThomsonTan]

We haven't discussed accept an user provided allocator. Would override the global operator new(...) work for non-default memory allocation scheme? Also do you know some similar projects which supports customized memory allocator?

[matgrioni]

I am not familiar with any other project that supports custom memory allocation. A quick look at the lightstep, jaeger, zipkin implementations show that they don't have support for this either (although perhaps such an implementation is at odds with the specification itself; I'm not sure).

Global new override would always work for choosing a new allocation strategy for the whole application, but I don't think that would work for choosing different allocation strategies in different sections of the application (hot path vs cold path processing).

[maxgolov]

Hello Matias,

I've been studying the code in this repo to understand the design of library components for such systems..

Could you please clarify your ask with more concrete example. Perhaps a benchmark? It should generally be possible to override the allocator using TCMalloc as a reference example.

For high(er) performance or throughput server applications, std::allocator is infeasible to use on the live path
of request processing, and so this library as is cannot be incorporated.

It would be invaluable for us to understand how you came to that conclusion. Having more concrete examples with Google Benchmark + concrete exporter kind would help. Most I/O and processing is done asynchronously within context of an OTLP exporter, for example.. Whereas in case of ETW exporter on Windows - we generally pass event buffers synchronously to high-perf ETW (kernel-based mechanism), without much network I/O, avoiding the unnecessary memcpy, and not needing an additional thread either.

Having more tangible instrumentation example (e.g. I instrumented nginx with and without OpenTelemetry, I see perf regression by xx% - would have helped. nginx and Apache Httpd instrumentations are available in contrib repo.