rudjigames/mtuner

1. What this repo builds

MTuner is split into two major runtime sides: a capture side that runs with the profiled application and records allocation history, and a desktop analysis side that opens the resulting capture and visualizes it. The desktop app is Qt-based and is currently functional on Windows; the capture SDK is designed to work more broadly.

2. Top-level code layout

The repository is organized around src/MTuner for the GUI application, src/libs for reusable support libraries, and src/tools for auxiliary capture/injection binaries. 3rd/unordered_dense is a vendored third-party dependency. The rest of the repo is mostly build scripts, resources, and localization assets.

3. Capture pipeline

The capture side centers on rmem-style allocator interception. It records every alloc, realloc, and free together with call stacks, thread IDs, heap/allocator identity, tags, sizes, and timestamps. The README indicates two deployment modes: Windows injection into an existing process, or SDK linking into the target application.

4. Capture file boundary

The output of the capture side is a portable .MTuner file, which is essentially a time-ordered history of memory operations. The capture path is optimized for low overhead: operations are serialized into compact records and written with LZ4 compression on a background thread.

5. Loader and in-memory model

Inside the desktop app, the loading boundary is handled by src/MTuner/src/loader/* and related classes such as capturecontext, binloaderview, and mtunerlib. These components parse the capture file, reconstruct the operation stream, and build the in-memory analysis model used by the rest of the UI.

6. Analysis layer

After loading, the app computes aggregate structures used for queries and drill-down: allocation statistics, grouped views, stack-trace trees, tag trees, module/thread/heap breakdowns, and the “Insights” findings. The design is explicitly history-based, so analysis is done over the whole timeline rather than a single live heap snapshot.

7. Visualization/UI shell

mtuner.cpp, mtunermain.cpp, centralwidget, and the many *.ui files define a dockable Qt application with multiple specialized views. The UI includes timeline graphs, histograms, treemaps, stack traces, hotspots, modules, threads, heaps, source, project management, operations lists/search, and the new Insights tab.

8. Visualization widgets as separate subsystems

The visual components are implemented as distinct widgets such as graph*, histogram*, treemap*, stacktrace*, stacktreewidget, hotspots, insightswidget, and sourceview. This separation matters architecturally: each view consumes the same loaded capture model but presents a different projection of the memory history.

9. Symbol resolution boundary

src/libs/rdebug and classes like symbolstore provide the symbol-resolution layer. On Windows this relies on PDB/DIA and the Microsoft public symbol server; for GCC/Clang toolchains it uses addr2line/nm. That resolution feeds stack traces, source links, and navigation from findings back into code.

10. Capture/injection tools

src/tools/MTunerCmd, MTunerDLL, and MTunerInject are supporting binaries for command-line control, injection, and runtime support. They form the operational boundary between the desktop analyzer and the profiled process, especially for the Windows injection workflow.

11. Shared support libraries

src/libs/rbase, rmem, rg_memory, rdebug, and rqt look like the reusable substrate for memory utilities, capture/runtime logic, debugging/symbol resolution, and Qt integration. These libraries reduce duplication between the desktop app and the capture-related tools.

12. Build and packaging architecture

The project is built with GENie/zidar and requires Qt plus Lua during generation. The repo includes scripts for Visual Studio 2022 and MinGW generation, AppVeyor CI config, and packaging scripts. Resources include fonts, icons, translations, and Qt resource files, which are all part of the shipped desktop application.