Skip to content

sdk: honor TraceConfig.compression_type on the in-process backend#5862

Open
dreveman wants to merge 1 commit into
mainfrom
dev/reveman/in-process-compressor
Open

sdk: honor TraceConfig.compression_type on the in-process backend#5862
dreveman wants to merge 1 commit into
mainfrom
dev/reveman/in-process-compressor

Conversation

@dreveman
Copy link
Copy Markdown
Collaborator

Mirror what src/traced/service/service.cc does for the system backend: when the SDK is built with enable_perfetto_zlib=true, construct the in-process backend's TracingService with init_opts.compressor_fn = &ZlibCompressFn so that TraceConfig.compression_type = COMPRESSION_TYPE_DEFLATE actually takes effect. Without this, the in-process service is created with default init_opts (compressor_fn == nullptr) and the compression_type field on the TraceConfig is silently ignored — embedders writing a local .pftrace via TracingSession::Setup(cfg, fd) got an uncompressed file regardless of what they set in the config.

The compressor is wired only when PERFETTO_ZLIB is enabled, matching the existing pattern in service.cc:136-139. No new public API; the behavior is opt-in via the TraceConfig field that already exists.

@dreveman dreveman requested a review from LalitMaganti May 13, 2026 22:40
@dreveman dreveman requested a review from a team as a code owner May 13, 2026 22:40
@github-actions
Copy link
Copy Markdown

github-actions Bot commented May 13, 2026

@LalitMaganti
Copy link
Copy Markdown
Member

I think this is not as simple as this: we also need to do what I said in #3118 - basically define some new #defines you can add to the SDK enabling ZLIB in the amalgmated SDK (but you are responsible for making zlib available to us).

@dreveman
Copy link
Copy Markdown
Collaborator Author

dreveman commented May 13, 2026

I think this is not as simple as this: we also need to do what I said in #3118 - basically define some new #defines you can add to the SDK enabling ZLIB in the amalgmated SDK (but you are responsible for making zlib available to us).

Works fine for me as long as I build the SDK with the following and add zlib dependency to my target:

tools/gen_amalgamated \
     --sdk cpp \
     --gn_args 'enable_perfetto_ipc=true enable_perfetto_zlib=true enable_perfetto_re2=false enable_perfetto_pcre2=false is_debug=false is_perfetto_build_generator=true is_perfetto_embedder=true perfetto_enable_git_rev_version_header=true use_custom_libcxx=false' \
     --output /tmp/perfetto-sdk/perfetto \
     //:libperfetto_client_experimental \
     //include/perfetto/protozero:protozero \
     //protos/perfetto/config:zero \
     //protos/perfetto/trace:zero \
     //src/tracing/service:zlib_compressor

I can work on adding a simpler flag to gen_amalgamated for this as a follow up if that's something we want? Either way, it would be nice to make this change so someone (like me) who is OK with maintaining a custom generated version of the SDK doesn't have to manually patch the code.

@LalitMaganti
Copy link
Copy Markdown
Member

Hmmmmm I thought the amalgamator stripped out the buildflags (at least that's what I say in the issue). I'm quite confused by this, will have to look into this a bit.

Mirror what `src/traced/service/service.cc` does for the system
backend: when the SDK is built with `enable_perfetto_zlib=true`,
construct the in-process backend's TracingService with
`init_opts.compressor_fn = &ZlibCompressFn` so that
`TraceConfig.compression_type = COMPRESSION_TYPE_DEFLATE` actually
takes effect. Without this, the in-process service is created with
default `init_opts` (compressor_fn == nullptr) and the
`compression_type` field on the TraceConfig is silently ignored —
embedders writing a local `.pftrace` via `TracingSession::Setup(cfg, fd)`
got an uncompressed file regardless of what they set in the config.

The compressor is wired only when PERFETTO_ZLIB is enabled, matching
the existing pattern in `service.cc:136-139`. No new public API; the
behavior is opt-in via the TraceConfig field that already exists.
@dreveman dreveman force-pushed the dev/reveman/in-process-compressor branch from f8baa8c to 7094e2f Compare May 14, 2026 01:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants