[Heaptrack] [Bug 426965] New: Cache heaptrack parse

https://bugs.kde.org/show_bug.cgi?id=426965 Bug ID: 426965 Summary: Cache heaptrack parse Product: Heaptrack Version: 1.2.0 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority:

[Heaptrack] [Bug 426965] Cache heaptrack parse

https://bugs.kde.org/show_bug.cgi?id=426965 --- Comment #1 from Andrew Somerville --- Addendum: * Loading takes 10s of minutes in the case of an 8GB file. * Unintentional process terminations (crashes, accidental window close) are of particular issue for heaptrack_gui -- You are receiving

[Heaptrack] [Bug 426973] New: Feat: recalculate graph based on time range

https://bugs.kde.org/show_bug.cgi?id=426973 Bug ID: 426973 Summary: Feat: recalculate graph based on time range Product: Heaptrack Version: 1.2.0 Platform: Other OS: Linux Status: REPORTED Severity: wishli

[Heaptrack] [Bug 426973] Feat: recalculate graph based on time range

https://bugs.kde.org/show_bug.cgi?id=426973 --- Comment #1 from Andrew Somerville --- Looks like you're already working on this, what timing! : ) I see something in 019a87c that seems like it might be on the way. Let me know if I can do anything to help. -- You are receiving this

[Heaptrack] [Bug 426965] Cache heaptrack parse

https://bugs.kde.org/show_bug.cgi?id=426965 --- Comment #3 from Andrew Somerville --- Looks like I got the original number wrong it's 4gb compressed with gz (and 65GB uncompressed! geeze) I'll try switching to zstd and see what the speed looks like. Also I started adding some informat

[Heaptrack] [Bug 409606] Track memory allocated with mmap

https://bugs.kde.org/show_bug.cgi?id=409606 Andrew Somerville changed: What|Removed |Added CC||andy.somervi...@gmail.com --- Comment #11

[Heaptrack] [Bug 409606] Track memory allocated with mmap

https://bugs.kde.org/show_bug.cgi?id=409606 --- Comment #12 from Andrew Somerville --- I created https://github.com/catskul/tizen-heaptrack to make comparison, PRs, and forking easier. I'll take a look later to see if there's any twidling I need to do to make it share history

[Heaptrack] [Bug 428689] New: Feature request: include allocation size information at top of flame graph

https://bugs.kde.org/show_bug.cgi?id=428689 Bug ID: 428689 Summary: Feature request: include allocation size information at top of flame graph Product: Heaptrack Version: unspecified Platform: Other OS: Linu

[Heaptrack] [Bug 428689] Feature request: include allocation size information at top of flame graph

https://bugs.kde.org/show_bug.cgi?id=428689 --- Comment #2 from Andrew Somerville --- > Would you think it should look like this: > > [1x 100b] > [a ] [1x 200b ] > [b ] [1x 200b ] [1x 100b] > [c

[Heaptrack] [Bug 428689] Feature request: include allocation size information at top of flame graph

https://bugs.kde.org/show_bug.cgi?id=428689 --- Comment #3 from Andrew Somerville --- It would seem that it might be possible to search the call stack some small number of frames for function names matching a regex and find allocators for type T and then lookup the sizeof info for T in the DWARF

[Heaptrack] [Bug 428689] Feature request: include allocation size information at top of flame graph

https://bugs.kde.org/show_bug.cgi?id=428689 --- Comment #5 from Andrew Somerville --- I'm going to experiment a little with `libdw` from `elfutils` just to inform myself a bit. I'm a newbie compared to you, but the idea has become interesting enough that I'm curious to learn mo

[Heaptrack] [Bug 391635] New: Expose file format parsing functions publicly for use by other systems

https://bugs.kde.org/show_bug.cgi?id=391635 Bug ID: 391635 Summary: Expose file format parsing functions publicly for use by other systems Product: Heaptrack Version: unspecified Platform: Other OS: Linux

[Heaptrack] [Bug 391635] Expose file format parsing functions publicly for use by other systems

https://bugs.kde.org/show_bug.cgi?id=391635 --- Comment #2 from Andrew Somerville --- I really love heaptrack. Thank you so much for writing it/ and putting in so much time! The particular use case on my end is that we're using heaptrack for continuous integration to compare successive ver

[Heaptrack] [Bug 391635] heaptrack_print: output to easily parsable data format

https://bugs.kde.org/show_bug.cgi?id=391635 --- Comment #5 from Andrew Somerville --- I'm not familiar with the flamegraph output format in enough detail, but at first glance I think it looks like it still requires pre-processing to get the relevant data back into an easily queryable