A few assorted suggestions

[gh-andre]

I've been using memray to profile a relatively large application and wanted to thank you for a wonderful tool, and also wanted to share a few observations in hopes you may find them useful. You can also safely ignore these, if you'd like :)

1. I noticed that a few stack frames were missing in one of my flame graph reports and after some digging a bit, I found the option --max-memory-records that seemed to help. It had no documented default value, and from looking at the source, it appeared to be set at 10K, although I'm not sure I'm looking at the right value. For my purposes I had to bump it up to 2,147,483,647 to see most spikes in the chart and expected call stacks.
   
   It would be nice if the default is documented, but I also would suggest to emit a warning if the selected value is less than the one in the Stats in the flame graph, which was 1.4B allocations in my case, so some stuff was not visible.

2. I couldn't set --max-memory-records past 2147483647 because of the error it was throwing, which seems to be limited to 32-bit integers in some Python/C++ integration code. It would be nice if this value was carried in a 64-bit value, like int64_t, which is the default integer size in most C++ apps nowadays.

3. The --aggregate option is useful for capturing data for long runs and I was able to use it for multi-hour captures, but I soon realized that even though it is not listed in limitations for aggregate captures, they cannot be used to generate temporal flame graphs and trying to do so just throws a not-implemented exception. Perhaps until it is implemented, it should be caught at the option parsing stage and print a user-friendly error that --temporal cannot be used for aggregate captures yet.

4. One of the challenges with a non-temporal flame graphs is to figure out where that call stack actually is on the time line. There is no high water mark or any other indication on the timeline, even approximate, so for a 10-hour capture of a backend app that does repeated processing of something, it's not even possible to place the call stack on the time line. At least I haven't found one, in case if I missed it. Perhaps adding a line in Stats that would print the time stamp at which the highest memory footprint was logged, even if it's approximate, could be the solution that doesn't need to touch the chart.

5. For temporal graphs, I would suggest to keep the high water mark at a minimum width, even if it's one pixel, which would make it possible to spot it at larger scales. Now it's quite tricky to locate the biggest one in a bunch of repeated work cycles without zooming in, but when zoomed in, it's not even clear if the water mark in this segment is actually the biggest, so a bunch of them need to be zoomed in and manually inspected to find the biggest amount.

6. The tooltip for the heap amount on the chart, the one with the orange background, has black text, which is harder to read, once you stared at a bunch of them for a while. I think rendering it similar to resident memory - as white, only on orange, would make it easier to look at it.

7. I found tooltips for stack frames hard to work with because quite often they block lower frames or those to the right from the one I'm pointing at, which makes it hard to read the chart left-to-right and down. Perhaps for icicles, tooltips should favor the area above the mouse pointer, since people mostly focus on lower frames in icicle charts.

8. Many function names are not visible in the call stack frames, which is expected, given their variable length, but not seeing the function name in a tooltip requires clicking on each and then clicking back on the upper frame just to explore the call stacks. If a tooltip would show a function name as well, it would simplify exploring busy call stacks.