4 ms·

> Did you read the linked article? From https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html: "Please don't commen

> Did you read the linked article? From https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html: "Please don't comment on whether someone read an article" And yes, I did, and I truly don't grasp even the 'simple' explanation. I already admitted I'm dumb. Do you have anything to add to the discussion?

nemetroid 2y ago
> Do you have anything to add to the discussion? Do you? Can you point out where it (edit: the simple example) breaks down, instead of just repeating that you're dumb?
- PreInternet01 2y ago
  By the 'simple example', I assume you mean https://tech.popdata.org/images/cps1970_before_fix_dwarf_gcc53.svg https://tech.popdata.org/images/cps1970_before_fix_dwarf_gcc...? If so, the widest, reddest, and highest-magnitude function I see there is __int__malloc. Right? Yet, reading on, it seems that has nothing to do with anything, and the actual culprit is Record::hasVariable, which is somewhere in the middle of the graph, and not any redder or less red, or wider or less wide, than many other functions. So, looking at just the first graph, how am I supposed to immediately spot the culprit?
  - vessenes 2y ago
    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.
    - PreInternet01 2y ago
      > 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...
  - nemetroid 2y ago
    By simple example, I mean this: https://tech.popdata.org/images/flamegraph-example.svg https://tech.popdata.org/images/flamegraph-example.svg But looking at the one you're referencing, slightly out of order: > highest-magnitude function I see there is __int__malloc. Height shows stack depth, not magnitude. > the actual culprit is Record::hasVariable, which is somewhere in the middle of the graph, and not any redder or less red, or wider or less wide, than many other functions. > not any redder or less red The colors are randomized to help with contrast (Brendan's website mentions this practice), so they aren't conveying any information. > or wider or less wide That's not really true. Hovering over Record::hasVariable tells that this bar covers 45.6% of the runtime. The only bars wider than that are the callers of Record::hasVariable (edit: rather, the stack through which Record::hasVariable is being called), i.e. the bars on which Record::hasVariable is resting. > somewhere in the middle of the graph Sure - being in the middle height-wise means that it's somewhere in the middle of the call stack. But there are some clues to its relevance: 1. It's close to the boundary between application code and standard library code. It does call MetaData::Cache::getVarsByName, which (going by the name) also is part of the application, but everything deeper in the stack (i.e. on top of those bars) is purely std:: stuff. 2. Domain knowledge. The text alludes to this: Record::hasVariable is a conceptually simple operation that's not expected to be a major part of the runtime. This does not mean that Record::hasVariable must be the culprit. Maybe some function higher in the call stack (e.g. EditingAPI::Rules::getSourceDataAsLong) is calling Record::hasVariable way too many times? But it's a good place to start looking.
    - PreInternet01 2y ago
      Ah, OK, so there is a graph, where magnitude is meaningless, colors are meaningless, runtime is relative, yet, with "enough domain knowledge" you can "see where the problem is right away"... I'm pretty sure we're done here.
      - nemetroid 2y ago
        > I'm pretty sure we're done here. Sorry to hear.

nemetroid 2y ago

> Do you have anything to add to the discussion? Do you? Can you point out where it (edit: the simple example) breaks down, instead of just repeating that you're dumb?

PreInternet01 2y ago
By the 'simple example', I assume you mean https://tech.popdata.org/images/cps1970_before_fix_dwarf_gcc53.svg https://tech.popdata.org/images/cps1970_before_fix_dwarf_gcc...? If so, the widest, reddest, and highest-magnitude function I see there is __int__malloc. Right? Yet, reading on, it seems that has nothing to do with anything, and the actual culprit is Record::hasVariable, which is somewhere in the middle of the graph, and not any redder or less red, or wider or less wide, than many other functions. So, looking at just the first graph, how am I supposed to immediately spot the culprit?
- vessenes 2y ago
  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.
  - PreInternet01 2y ago
    > 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...
- nemetroid 2y ago
  By simple example, I mean this: https://tech.popdata.org/images/flamegraph-example.svg https://tech.popdata.org/images/flamegraph-example.svg But looking at the one you're referencing, slightly out of order: > highest-magnitude function I see there is __int__malloc. Height shows stack depth, not magnitude. > the actual culprit is Record::hasVariable, which is somewhere in the middle of the graph, and not any redder or less red, or wider or less wide, than many other functions. > not any redder or less red The colors are randomized to help with contrast (Brendan's website mentions this practice), so they aren't conveying any information. > or wider or less wide That's not really true. Hovering over Record::hasVariable tells that this bar covers 45.6% of the runtime. The only bars wider than that are the callers of Record::hasVariable (edit: rather, the stack through which Record::hasVariable is being called), i.e. the bars on which Record::hasVariable is resting. > somewhere in the middle of the graph Sure - being in the middle height-wise means that it's somewhere in the middle of the call stack. But there are some clues to its relevance: 1. It's close to the boundary between application code and standard library code. It does call MetaData::Cache::getVarsByName, which (going by the name) also is part of the application, but everything deeper in the stack (i.e. on top of those bars) is purely std:: stuff. 2. Domain knowledge. The text alludes to this: Record::hasVariable is a conceptually simple operation that's not expected to be a major part of the runtime. This does not mean that Record::hasVariable must be the culprit. Maybe some function higher in the call stack (e.g. EditingAPI::Rules::getSourceDataAsLong) is calling Record::hasVariable way too many times? But it's a good place to start looking.
  - PreInternet01 2y ago
    Ah, OK, so there is a graph, where magnitude is meaningless, colors are meaningless, runtime is relative, yet, with "enough domain knowledge" you can "see where the problem is right away"... I'm pretty sure we're done here.
    - nemetroid 2y ago
      > I'm pretty sure we're done here. Sorry to hear.