red flame
Photo by JERRY / Unsplash

Just as I experienced with this very blog post you're reading right now, knowing how to start may just be the hardest part of a great many things.

When you've just run your profile – which I'm planning to make easier in the future as well – and you're looking at the overview page, you're really getting an overview of the very broadest kind. How long did the program run? Did it spend a lot of time running the GC? Are many routines not optimized or jitted?

However, profiling is usually used to find the critical little piece of code that takes an extraordinary amount of time. This is where your optimization attempts should usually begin.

Until now, the overview page didn't mention any piece of code by name at all. This changed when I brought in a flame graph (well, icicle graph in this case).

Here's two screenshots to give you an idea what I'm talking about:


Clicking on a box in the flame graph will expand the node to be 100% the width of the full graph so you can inspect the descendant nodes more easily. Here I've selected the step function:


Selecting one of the nodes gives the name of the routine, the source code line and links to the node in the call graph explorer (the rightwards arrow button) and to the routine in the routine list. On top of that, the filename and line number below the routine name are clickable if they are from the core setting, and they take you right to the implementation file on github.

The next step is, of course, to also put flame graphs into the call graph explorer. I'm not entirely sure how to make it behave when navigating upwards to the root or downwards to the selected children, i.e. whether it should keep nodes towards the root or how many.

That's already everything for today. I couldn't invest terribly much time into moarperf this and last month, but I'll continue working :)

Have a good one, and thanks for reading!
  - Timo