Perfetto: Swiss army knife for Linux client tracing

SQL interface for querying traces is the real killer feature though.

This kind of thing always feels too slow to use. Every time I open my trace in it, it always lags and requires a few seconds to zoom in or zoom out.

Does anybody have advice on how to embed perfetto UI into local tool? I'm currently using the old catapult chrome trace viewer to visualise and inspect scheduler outputs but there are some shiny features in perfetto that would be great.

Background: My company designs machines that automate medical laboratory tests. Many applications have a fun scheduling problem at their core, think 'job shop' with a bunch of biology-enforced constraints.

To help design these systems our tool allows an engineer to (a) enter a 'recipe' and resource constraints of a hypothetical system (b) use our fancy scheduling engine to simulate the system, (c) output a 'trace' of how each piece of equipment is scheduled and (d) display some basic statistics.

Currently this is implemented as a single .html file - the GUI is vanilla js, the scheduler is cross-compiled to wasm and embedded and the output trace json is injected into an iframe containing chrome trace viewer.

Because the design process is quite iterative, a single button press to run the simulation and display the output is desirable.

I understand that perfetto has chosen not to support embedding, fair enough. plugins seem to require hosting/maintaining my own fork. Any other ideas?

oooh fantastic. Thanks! Exciting

My initial test looks pretty good, seems I will need to muck around a bit to get to "one click runs the simulation and displays the trace and stats" but that rust link seems to have clues.

It sure is pleasing to see perfetto handles long durations well - we work in hours and days not ns and us...

I don't suppose there is some supported way to inject macros or "ui automation" [1] into the iframe?

[1] https://perfetto.dev/docs/visualization/ui-automation

Perfetto is kind of a weird tool because it seems to be designed around tracing Linux and Android but overwhelmingly it gets used because of their integration with the exceptionally simple JSON tracing format that takes like 2 seconds to implement in whatever tool you are using. This alone is profoundly useful and I greatly respect the impact they have had towards commoditizing "trace viewing". I've gotten so much mileage out of it because of that.

I understand that Google maintains and uses this tool for their own thing but I kind of wonder if the UI should just get split off into its own thing, because I get the impression that they don't even really particularly like supporting what everyone else is using it for. I know the maintainers are around here is around so perhaps they have more context but it's just very strange to me that the UI will always be showing things like "syscall trace" or "connect a device" when I am looking at GPU kernels or network spans. And I get the impression that the JSON format is considered to be kind of grandfathered in and not really what they like supporting. I guess in a sense it's a little weird that most of the people I know use it like the flamegraph viewer tool for traces but it views itself as the one-stop-shop for your Android performance profiling that just happens to have good import for recorded profiles.

Also, I repeat this a lot, but I think a lot of profiling tools could stand to learn things from Apple's Instruments. I don't really know what they are doing over there but their UI is almost always the best for actually finding what the problem is rather than just dumping data at you like what a lot of profiling tools do (especially for Linux). Notably it's had the "bottom up" view for a very long time because I assume the Apple engineers who work on like malloc use it a lot. It's even weirder and more proprietary in the ways I mentioned above while also not having any sort of import feature, so I understand why nobody seems to know about it or steal design ideas from it, but it's slept on. Arguably I don't even think people should be using it for general-purpose use because it's ironically slow and laggy in ways that Perfetto definitely isn't, but it is exceptionally good at common tasks like "zoom into this region" or "let me quickly jump to the part of this call stack that is a problem" that I have not seen anywhere else.