Re: [PATCH 0/2] perf python: Add an example for sampling

[Ian Rogers]

On Wed, Sep 17, 2025 at 9:41 AM Arnaldo Carvalho de Melo
<acme@xxxxxxxxxx> wrote:
>
> On Wed, Sep 17, 2025 at 08:29:24AM -0700, Ian Rogers wrote:
> > On Wed, Sep 17, 2025 at 5:37 AM Arnaldo Carvalho de Melo <acme@xxxxxxxxxx> wrote:
> > > And make:
>
> > > perf script rwtop
>
> > > Just call 'python PATH_TO_PYTHON_SCRIPTS/rwtop.py' transparently?
>
> > Yeah, that's it. The perf script libpython stuff is just providing
> > trace_begin, process_event and trace_end. Using the sampling
> > mechanism, as shown in Gautum's patches, it is pretty easy to migrate
> > them to being stand alone bits of python.
>
> > > That looks interesting indeed, that way we would stop linking with
> > > libpython, etc.
>
> > > I wonder if there are out of tree scripts using the current tools/perf/util/scripting-engines/trace-event-python.c
> > > mechanism...
>
> > > But even that can fallback to a python based mechanism, right?
>
> > I think so. Like I said about the use of a Dict for process_event, we
> > may want to streamline things so there is a tension with what the API
> > should be and compatibility. We can always have 2 APIs and try to
> > deprecate one of them.
>
> > > Import the script, if it has a given structure, use the new way, if not,
> > > call a glue that reads the events and feed to the old style code.
>
> > > Seems doable and would save code on the main perf binary and headaches
> > > with the libpython and libperl build processes.
>
> > So I see this for libpython, and I think it'd be pretty cool if we
> > could have things work like this for say "perf script ilist" and
>
> I think we could even try to, not having a builtin-ilist.c convert
> 'perf ilist' to 'perf script ilist' automagically.
>
> > Alice's textual flamegraph work. I worry what the work for libperl
> > would be like and whether it is worth it (hence sending the patch to
> > at least start to make it opt-in rather than opt-out).
>
> Maybe we should be a tad more cautious and start with emitting a warning
> that "libperl is deprecated (holler if you disagree if you use it!)" and
> then make it opt-in, and then remove it.

Not sure I follow, let's move the conversation to that patch.

> > Do you need my tags for these changes or wdyt about making the
> > kwlist/API surface smaller?
>
> Lemme look at the original post...

Thanks,
Ian

> - Arnaldo