As more indirection gets introduced in MediaWiki via factories and service classes, the stack traces are gaining two or three extra layers around the bottom of the chart, and also 2-3 layers toward the peak of any flame.
The peaks are where most of the leaf nodes are, and is where most of the "real" computations happen. Omitting narrow and tall sub stacks from that is fine if they are insignificant in terms of time spent overall. But, the threshold is based the pixel-width at the highest zoom level (zoomed out).
I'm noticing that more and more often the interesting bits in the peak are now cut off, and thus I can no longer see where peaks are spending there time (and thus not know what could be optimized in them).
For example, getKnownCurrentRevision does not have any children in this graph:
In this case I was able to use the reverse graph to find a few more frames, but that's not great from a UX perspective, and won't always work:
We added this originally in 2017 (patch), to reduce the size of the SVG files and to keep them fast to render.
The FlameGraph upstream default for minwidth is 0.1px. Perhaps we can try using --minwidth=1 and see how large our files would be, and if they still render at an acceptable speed.
