Using the C SDK

[carloscaballero-tomtom]

Hola!

Nice to chat to you all again :)

I am looking into using the Perfetto SDK to instrument some code that is a bit of a mix of languages, so I will need to write some wrappers, similar to what you seem to have started with the android_sdk. Using the C++ SDK forces me to define all trace categories in one C++ header file (or multiple when using namespaces but that means I now have multiple datasources registered). This is a bit inconvenient as I might want to define categories in one of the other languages (e.g. Java). I see that you are using the new libperfetto_c library for your android_sdk project, and in fact the c SDK has a nicer API to register categories. That made me consider using the C API instead but all I could find about it is a mention in the docs “A C SDK is under active development and should be available for general usage by Q2 2023”. So I have a couple questions related to this C SDK.

• Is the libperfetto_c production ready?
• Is the API for the c library stable? I.e. if I start instrumenting all my code I can I be sure I will not need to rewrite all of it in a newer Perfetto version? I do not care so much about the ABI (see next question)
• I do not really need the shared library I am mainly interested in the more convenient API and I will export my own functions to the other languages that under the hoods call into the perfetto lib. Is there any reason to not statically link that code? I see you do it for tests so it is technically possible :)
• What are the tradeoffs to consider between the c and the c++ SDK?
• What are the plans for the android_sdk? It looks really useful!! :)
• Are you planning to add the same trace category registration mechanism to the c++ library?

Thanks!

[ddiproietto]

Hi!

Is the libperfetto_c production ready?

Yes, as much as the C++ API at this point.

Is the API for the c library stable? I.e. if I start instrumenting all my code I can I be sure I will not need to rewrite all of it in a newer Perfetto version? I do not care so much about the ABI (see next question)

Mostly. We had one ABI breakage since the code was checked in, but zero API breakages. I don't expect API breakages in the future.

Is there any reason to not statically link that code?

None at all. You can statically link the code.

What are the tradeoffs to consider between the c and the c++ SDK?

Disadvantages of the C API compared to the C++ API:

• The C++ API is more used/tested.
• Writing complicated custom protos is easier with the C++ API (with the C API you can write simple custom protos or you can use the low level API, but it's more complicated).
• Complicated track structures are better supported in the C++ API (but I plan to work on this).
• We don't provide an amalgamated build yet (but we will at some point)
• The C++ API allows custom interning for custom types (with include/perfetto/tracing/track_event_interned_data_index.h). There are no plans for anything similar in the C API.

Advantages of the C API:

• Better category registration
• dynamic linking
• Less binary size overhead for each native instrumentation point

What are the plans for the android_sdk? It looks really useful!! :)

It's the start of a java API, mostly for android. Not stable yet.

Are you planning to add the same trace category registration mechanism to the c++ library?

No plans. I'd love to be proven wrong, but I don't think this can be retrofitted easily at this point.

Hope this helps!

[carloscaballero-tomtom]

Thanks so much for the detailed response. This was really helpful!

Just a couple of followups.

• We don't provide an amalgamated build yet (but we will at some point)

I see you have #713 for this. Is this just a matter of calling tools/gen_amalgamated during your release process or is there any other work that needs to happen before? If so I might be able to help.

It's the start of a java API, mostly for android. Not stable yet.

Is there more detail about this anywhere? I was unable to find an issue for this.

[ddiproietto]

Thanks so much for the detailed response. This was really helpful!

Just a couple of followups.

• We don't provide an amalgamated build yet (but we will at some point)

I see you have #713 for this. Is this just a matter of calling tools/gen_amalgamated during your release process or is there any other work that needs to happen before? If so I might be able to help.

The main blocker is that we need to make some decisions on export macros and whether to amalgamate the headers as well.

It's the start of a java API, mostly for android. Not stable yet.

Is there more detail about this anywhere? I was unable to find an issue for this.

Nothing else, we're just experimenting with the code you see in the repo for now.