I haven’t read the article. However, here is how I read the chart:
Record::hasVariable takes a long time. You can see that because it’s wide and red. The immediate ones below it on the chart don’t do anything but call it; you can see that because they are basically the same width. hasVariable splits into two calls (the row above). I’m going from memory here because I don’t have the chart here, but I think it should be clear from the trace:
A) hasVariable takes a lot of compute time
B) from the name, this seems surprising / non optimal.
C) Digging into the functions above it will yield chances to optimize.
I do agree that the malloc is sort of a surprising amount of the total percentage of hasVariable. Again, just from the flame graph and function names, I’d bet that some memory allocations are being done in a loop inside and would be much faster to allocate outside the hasVariable call, and get reused.
> Record::hasVariable takes a long time
As does Memdata::Cache::getVarsByName[blah] right above it, and many functions below (unsurprisingly, but still...), and they all have pretty much the same width and color.
The point of flame graph proponents is that "you see where the problem is right away."
My question is: "how, exactly?" And the answers so far seems to be mostly... lacking, to the point that I now officially declare flame graphs a cargo cult that is in no way superior to my "hierarchical bar charts" religion...