hckrnws

Very cool but also more interesting is using Perl for any newish project.

It is hard to find maintainers or developers knowing Perl nowadays. Especially in data science related projects as python has been the de-facto tool for that field for some time now.

Indeed, but it was easier to implement the logic since original flamegraphs are in Perl.

The video from the presentation on this: https://youtu.be/tdx9leN2kBg?si=uYa7xsOvpoonjaxB

This was part of the MySQL Belgian Days that was organized in the days before FOSDEM.

Any slides maybe?

You can find the slides here: https://github.com/vgrippa/presentations/blob/main/2026_FOSD...

Hah I did this for SQL Server execution graphs at one point (via profiler or extended events) and then I of course realized that anything that goes more than one or two events deep is just hellish SQL anyway, love to see the execution plan version that's much smarter.

That feeling when your fancy graph points out the obvious, and ‘bad thing bad’ is the only takeaway.

Data science <pew pew>!

Do you have slides from your FOSDEM presentation? The video has this funny angle :(.

Hi!

The slides can be found here: https://github.com/vgrippa/presentations/blob/main/2026_FOSD...

Thanks for sharing!

If I were in vgrippa's place, I would have not produced flamegraphs, but treemaps. It's the far superior choice for visualising profiling/query plans and the like, no matter along which property one would measure.

Munging the mysql output into something that is delectable as input to kcachegrind is straight-forward. Screenshots: https://ddg.gg/?q=%21i+kcachegrind

Thanks for the suggestion. Actually I received some feedback to produce something like flamescope from netflix https://github.com/Netflix/flamescope

I will take a look at the treemaps and try to incorporate.

Thanks for posting!