Introducing Flamez
I saw a tweet somewhere that pointed to Daniel Hooper's build time visualizer. He's got a callout at the end to try it, but I honestly don't have any sufficiently large projects where running this would be interesting and didn't want to bother asking for access. This project obviously takes inspiration from the original!
At the same time, I was playing around with ClayUI + raylib combo and figured I'd could see how far gpt-5.6 sol could go in building one for me. It basically built it, though not quite in one shot. I just guided it to use eBPF for linux and let it figure everything else out. I knew just enough about eBPF that it should have sufficient access to all the data we need to build this GUI, but nothing else. Majority of the additional prompting was for:
- Improving visuals
- Improving performance
- A few bugs
The more I knew exactly what I wanted, the better sol would perform in general. Mod one really weird bug1, it was actually quite smooth sailing.
I also asked for these features so that maybe this tool could be useful one day (but really this is just a for fun vibe coded project):
- Timeline zoom/keyboard/mouse support: easily zoom in and out with
ctrl+(mouse wheel)orctrl+-/ctrl+=(to reset:ctrl+0) - Thread CPU usage: with just the parent/leaf bars, we need to guess why the parent node is "idle". Seeing the CPU usage per bar at least lets us disambiguate I/O time with CPU time (e.g if the parent process is performing work in a thread pool vs being blocked by I/O).
- Detailed pane: this shows the exact command and args passed, it also follows
exec's so we can see what the original command was before the process got taken over by another command. - Import/export: the entire trace data can be exported (and imported) via a single JSON file
- Anylsis mode: a lossy conversion of the trace file ideally fit for agents to
troubleshoot any build slowdowns faster, though haven't seen it be that useful
yet. (Without actual integration into build tools,
flamezwill never have the sufficient context to build a real DAG. It's hueristics all the way down.)
Some random builds for fun (these are fully collapsed, these are run on a 32-core machine so traces get deep):
It even supports macOS. I don't know anything about the underlying APIs used, though supposedly in macOS 27, there's a better API being released, hence the "best effort" label for now:
After becoming a father this year, it's amazing I can still work on these side projects (and actually finish them). Queuing up a bunch of work and coming back to seeing your asks mostly met is honestly a big hit of dompamine.
-
In KDE, the dock will display a volume icon if that window is playing sound. I had helium (chromium-based browser) playing a video and noticed that flamez was also getting the volume icon... Something in KDE was saying that
helium app_id == flamez app_idwhich is obviously false. I checked that helium properly sets theapp_idin wayland. Flamez did not have anapp_idset though. And it turns out there's some bug somewhere in the pipewire/KDE stack that is causing pipewire to see helium'sapp_idas"". Flamez'app_idwas also""because it didn't have one. So due to"" == "", that bad volume association bug happened. Ideally, I'd submit a bug report to KDE, but I don't know enough of the problem to write a coherent bug report. The fix for flamez also required a patch to raylib. It's wayland GLFW backend currently resets all window hints and doesn't allow setting hints before the window gets drawn. Raylib is vendored in this project, so I just added a small workaround (too hacky to upstream). ↩