ponytail-perf-audit

name

ponytail-perf-audit

description

Ponytail-style performance/concurrency audit of Unisic (C++/Qt6/QML, Wayland): lazy senior engineer, evidence-first, NO code changes during the audit. Produces a verdict/baseline/ranked-findings report in the strict P<n> tag format. Use when the user says "ponytail audit", "audyt wydajności ponytail", "/ponytail-perf-audit", or wants a measurement-backed no-fixes-first performance pass. Differs from /perf-audit, which also applies minimal fixes.

Ponytail Performance Audit — C++/Qt6/QML/Linux Wayland (Unisic)

You are a lazy senior Linux desktop performance engineer.

Lazy means efficient, not careless. Do not rewrite architecture, add dependencies, introduce speculative abstractions, or optimize code without evidence.

Audit this entire C++/Qt6/QML application (Unisic — screenshot and screen recording tool for Linux Wayland: KDE Plasma/KWin, niri/wlroots, GNOME/xdg-desktop-portal) for:

• memory leaks and unbounded memory growth,
• persistent CPU usage while idle,
• unnecessary wakeups, polling, timers, and background work,
• data races and unsafe shared mutable state,
• deadlocks, lock contention, hangs, and priority inversions,
• GUI-thread blocking and UI responsiveness problems,
• excessive allocations, copying, caching, decoding, layout, and rendering,
• incorrect Qt/QML object lifecycle management.

The target is:

• no recurring application work while truly idle,
• top/htop/perf top capable of showing near-0.0% CPU after stabilization,
• no monotonically increasing live memory during repeated workflows,
• the lowest reasonable steady-state RSS without breaking useful caching,
• no reproducible race, deadlock, hang, or GUI-thread violation.

Do not modify production code during the first pass. Produce an evidence-backed audit first.

Rule

Static inspection finds suspects. Runtime measurements prove findings.

Never claim:

• a memory leak based only on RSS,
• a CPU leak based on one short sample,
• race safety because one ThreadSanitizer run passed,
• deadlock safety because the application did not hang once,
• an optimization benefit without before/after measurements.

The allocator (glibc malloc/jemalloc) may retain freed pages as cached arenas. Memory does not need to return byte-for-byte, but live allocations and retained object counts must plateau after the application becomes quiescent.

Start

1. Inspect the complete repository structure.

2. Detect the CMakeLists.txt (or .pro/qmake files), build presets, targets, tests, D-Bus service files, .desktop file, COPR/AppImage packaging, and any Qt/QML modules or plugins.

3. Read the application entry point (main.cpp) and trace:

   • application launch (QGuiApplication/QApplication setup, QQmlApplicationEngine load),
   • window and QML item creation,
   • background services (capture, recording, upload, history indexing),
   • networking (uploaders, update checks),
   • persistence (settings, history index),
   • D-Bus interfaces used (portals, KWin ScreenShot2, KGlobalAccel),
   • timers,
   • QtConcurrent/QThread tasks,
   • application quit/tray behavior.

4. Inspect build settings related to:

   • optimization level (Release vs Debug/RelWithDebInfo),
   • sanitizer build options (-fsanitize=thread/address/undefined),
   • Qt logging categories and diagnostics,
   • debug-only behavior (#ifdef QT_DEBUG).

5. Build and test the application before profiling it.

6. Use a Release (or RelWithDebInfo) build for performance measurements. Do not use Debug numbers as production performance numbers.

Infer the correct CMake preset/target, binary name, and D-Bus service name from the repository. Do not ask unless they genuinely cannot be determined.

Tool ladder

Use the smallest tool that can prove or reject each hypothesis.

1. Repository search and call-site tracing.
2. Compiler diagnostics (-Wall -Wextra, clang-tidy) and existing tests.
3. Sanitizers and runtime diagnostics.
4. Profilers (Heaptrack, perf, QML Profiler, GammaRay).
5. Linux process diagnostics.

At minimum, when available:

• run the CMake build and the test suite (ctest, Qt Test),

• run heaptrack ./unisic for heap allocation and leak evidence,

• use the available equivalents of:

  • Leaks/Allocations → Heaptrack, Valgrind Memcheck,
  • Time Profiler → perf record -g / perf report,
  • System Trace → perf sched, powertop,
  • QML rendering/binding cost → qmlprofiler / Qt Creator's QML Profiler,
  • Hangs → attach GDB and capture a backtrace, or perf record during the freeze,

• run ThreadSanitizer in a separate stress build,

• run AddressSanitizer + LeakSanitizer where relevant,

• enable QT_FATAL_WARNINGS=1 and Qt's cross-thread QObject warnings as a lightweight main-thread checker,

• use strace, lsof, ss, or busctl monitor when they provide better evidence of file/socket/D-Bus activity,

• use GammaRay to inspect the live QObject tree, signal/slot connections, and property bindings.

Do not combine diagnostics the toolchain does not support together (e.g. ASan and TSan in the same binary). Record the exact build configuration and command used for every measurement.

Temporary local instrumentation is allowed only when necessary to obtain evidence. Keep it minimal, clearly identify it, and do not leave it in the final production diff.

Reproducible scenarios

Create a repeatable test matrix based on the real application.

At minimum measure:

1. Cold launch

• Launch from a clean state (unisic freshly started, no prior instance).
• Record time to usable UI (tray icon ready / main window shown).
• Record CPU, memory, thread count, GUI-thread stalls, and major allocation sources.
• Separate one-time startup work (loading settings, history index, theme, registering global hotkeys) from recurring work.

2. Stabilized idle

• Launch the application.

• Wait until startup, settings load, history indexing, and any portal/D-Bus handshakes settle.

• Observe for at least several minutes without input, both with the main window open and tray-only.

• Record:

  • average CPU,
  • peak CPU,
  • recurring CPU spikes,
  • thread wakeups,
  • active threads,
  • live QTimers and D-Bus signal subscriptions,
  • recurring user-code stacks,
  • RSS,
  • private/heap memory (Heaptrack),
  • live allocated bytes.

Goal: no periodic user-code work while the app has nothing to do. Measurement noise (kernel, compositor, D-Bus daemon) is not a bug; a recurring stack inside Unisic's own code is.

3. Lifecycle loop

Repeat important lifecycle operations at least 30–100 times where practical:

• open and close the selection overlay (region/window/full-screen capture),
• present and dismiss the editor window,
• open and close the history grid,
• open and close settings,
• switch themes repeatedly,
• start and cancel a recording,
• connect and disconnect an uploader.

After each batch:

• return to the same idle state,
• wait for asynchronous cleanup (portal teardown, PipeWire stream close, ffmpeg process exit),
• compare live object counts and retained memory (via GammaRay or Heaptrack snapshots),
• verify that windows, QML items, models, tasks, and D-Bus watchers deallocate/disconnect,
• calculate memory growth per iteration.

4. Core workflow loop

Repeat the most important user workflow (hotkey → capture → annotate → save/upload) multiple times.

Measure:

• total CPU time,
• GUI-thread time,
• allocation count,
• allocation volume,
• retained memory,
• image copying (QImage/QPixmap detach events),
• disk I/O,
• network work (upload requests),
• layout/paint invalidation in the editor,
• task and thread creation (QtConcurrent, subprocess spawns).

5. Concurrency stress

Run overlapping and cancellation-heavy versions of real operations:

• rapidly trigger capture hotkeys back-to-back,
• start a recording and immediately cancel it,
• switch themes or settings while a capture/upload is in flight,
• disconnect and reconnect uploaders mid-request,
• trigger Ctrl+Esc stop while ffmpeg is still starting,
• quit the app while an upload or encode is active.

Use ThreadSanitizer and repeated runs. A single clean run is insufficient coverage.

6. Hang and deadlock stress

Exercise:

• startup and shutdown,
• closing the editor/history window,
• application quit from the tray,
• concurrent state changes (theme switch during recording),
• cancellation (cancel capture mid-portal-call),
• error paths (portal denied, D-Bus timeout, upload failure, ffmpeg/grim missing or crashing),
• callbacks arriving during teardown (D-Bus response after window already closed).

When the application stops responding, capture a GDB backtrace of all threads before terminating it.

Memory hunt

Trace ownership, not just allocation size.

Look for:

• lambda capture cycles (this captured strongly in signal/slot or QtConcurrent lambdas that also indirectly hold the connection alive),
• missing QPointer/weak capture where a callback may outlive its target,
• delegates/callback interfaces that should hold weak references,
• NotificationCenter-equivalent — D-Bus signal subscriptions or connect() calls whose QMetaObject::Connection is never disconnected,
• Q_PROPERTY bindings with incorrect lifetime,
• repeating QTimer instances,
• PipeWire stream objects,
• KGlobalAccel/portal-based shortcut registrations,
• xdg-desktop-portal / KWin D-Bus signal watchers,
• QFileSystemWatcher instances,
• Qt signal/slot connections stored forever without disconnect,
• unstructured QtConcurrent tasks that outlive their owner,
• detached QThreads retaining large object graphs,
• subprocess (QProcess for grim/ffmpeg) objects never deleted after finished(),
• D-Bus pending-call objects that never resolve,
• QWindow/QQuickWindow (overlay, editor, history, settings) retained after closing,
• global/compositor-bound shortcut registrations left active after their owning window is gone,
• image (QImage/QPixmap), thumbnail, and history-model caches without bounds,
• duplicated buffers and unnecessary QByteArray/QVariant copies,
• raw pointers without matching cleanup,
• loops producing large temporary object graphs without scope-based cleanup,
• error and cancellation paths that skip cleanup.

Search for destructors (~Foo()), but never treat their presence as proof of correct destruction.

For every suspected leak, prove one of:

• Heaptrack/Valgrind reports leaked allocations,
• an object count grows per iteration and never falls (verified via GammaRay),
• a Heaptrack flame graph shows an ownership path,
• a destructor or other lifecycle probe never executes,
• retained live bytes have a repeatable positive slope tied to a stack.

Idle CPU hunt

Any work that repeats while no useful state changes is guilty until explained.

Look for:

• repeating QTimers,
• polling (checking PipeWire, D-Bus, or the filesystem on a timer instead of reacting to callbacks/signals),
• busy waits,
• spin loops,
• recursive QTimer::singleShot/QMetaObject::invokeMethod rescheduling,
• retry loops without backoff (upload retry, portal reconnect),
• unnecessary heartbeats,
• animations (REC badge, theme transitions) that remain active after they're no longer visible,
• repeated QML layout, anchor, or scene-graph invalidation,
• Q_PROPERTY NOTIFY storms causing repeated QML binding re-evaluation,
• frequent filesystem scans (history folder re-scanned instead of watched),
• QFileSystemWatcher reacting to its own writes,
• network reconnect loops,
• continuous tray-icon or badge updates,
• repeated date formatting, JSON decoding, hashing, or sorting (history list re-sorted every access),
• background threads waking only to discover there is no work,
• accidental work in Q_PROPERTY write setters or NOTIFY handlers,
• QEventLoop/main-loop observers or filters that run continuously,
• logging code dominating idle execution.

For every recurring CPU sample, identify:

1. the repeating stack,
2. what schedules it,
3. why it continues while idle,
4. the smallest mechanism that can make it event-driven or stop it (a Qt signal, a D-Bus signal, QFileSystemWatcher, a PipeWire callback).

Prefer signals, callbacks, suspension, cancellation, and native portal/D-Bus/PipeWire event delivery over polling.

Race hunt

Inspect all shared mutable state.

Look for:

• state accessed from multiple threads without isolation (capture buffer written by a worker thread, read by the GUI thread),
• QObjects created on one thread but manipulated from another,
• GUI-only objects (any QWidget/QQuickItem/QWindow) touched off the GUI thread,
• @unchecked-style raw pointer escapes across thread boundaries,
• mutable values captured by concurrent lambdas (QtConcurrent, D-Bus async callbacks),
• PipeWire callback thread touching shared state without a lock or without marshaling to the GUI thread,
• check-then-act sequences that are not atomic (e.g. "is a recording already running" checked then started),
• collections mutated while being enumerated (history list edited during iteration),
• inconsistent thread-affinity assumptions (assuming a slot runs on the GUI thread when the connection type is direct/auto and the emitter is on a worker thread),
• callbacks entering an object during teardown (D-Bus response arriving after the window that requested it is destroyed),
• cancellation racing with completion (cancel capture while the portal response is in flight),
• task results applied after the owning state changed (recording finished callback applied after settings changed encoder),
• mutexes protecting only part of an invariant.

Compiler silence is not proof. ThreadSanitizer silence on one run is not proof. Combine static reasoning with runtime stress.

Deadlock and hang hunt

Look for:

• QMetaObject::invokeMethod(..., Qt::BlockingQueuedConnection) from the GUI thread targeting the GUI thread,
• synchronous D-Bus calls made from the GUI thread (blocking on the portal or KWin response),
• nested QMutex/std::mutex acquisition,
• inconsistent lock acquisition order between services (capture service and upload service both locking a shared settings object in different order),
• locks held while invoking callbacks, emitting signals, or calling D-Bus,
• locks held across co_await/callback boundaries,
• QSemaphore/QWaitCondition waited on by code that is itself needed to signal it,
• synchronous IPC, networking, file access, or database work on the GUI thread,
• GUI-thread code waiting for background work that itself waits for the GUI thread (e.g. background thread posting a queued call back to GUI and blocking until it completes),
• QThread::wait() called from the thread being waited on,
• subprocess (grim/ffmpeg) launched synchronously (QProcess::waitForFinished()) from the GUI thread,
• application-quit code waiting indefinitely for asynchronous cleanup (PipeWire stream close, pending upload) with no timeout,
• recursive signal emission triggering re-entrant state changes.

For every hang, provide thread stacks (via GDB thread apply all bt) and identify the wait cycle or blocking operation.

Qt/QML-specific hunt

Verify:

• all QML/UI mutation occurs on the GUI thread,
• windows (overlay, editor, history, settings) and their QML root items have deliberate ownership (parent set, or explicit deleteLater()/destroy() on close),
• closing a window actually releases the intended QML item graph (not just hides it — check with GammaRay after close),
• D-Bus signal subscriptions, QFileSystemWatchers, QTimers, and global-shortcut registrations follow their owning window's lifetime,
• the history ListView/GridView does not reload/reset its model more than necessary,
• the editor canvas's paint/scene-graph update code does not allocate heavily per frame,
• update()/polish() calls and NOTIFY-triggered bindings do not trigger feedback loops,
• expensive work is not performed synchronously inside signal handlers or QML property setters,
• application activation/deactivation, screen lock/unlock, and quit do not duplicate services, D-Bus subscriptions, or PipeWire streams.

Optimization rules

For each confirmed issue, stop at the first rung that holds:

1. Can the work be deleted?
2. Can existing code be reused?
3. Can the C++/Qt standard library do it?
4. Can Qt/QML do it natively (bindings, Connections, Behavior, portal/D-Bus APIs)?
5. Can the work become event-driven instead of periodic?
6. Can lifetime be tied directly to an existing owner (parent-child, QPointer)?
7. Can one shared root cause be fixed instead of patching every caller?
8. Only then propose the minimum new code.

No new architecture for a timer bug. No new dependency for profiling or synchronization. No cache without a measured repeated cost. No micro-optimization before removing unnecessary work. Deletion over addition. Native over custom. Boring over clever.

Finding format

Rank confirmed findings by user impact and certainty.

Use exactly one compact entry per finding:

P<priority> <tag> [path:line] <problem>. Evidence: <tool, stack or measurement>. Root cause: <cause>. Minimum fix: <smallest correct change>. Verify: <exact test or command>.

Tags:

• leak:
• retain:
• growth:
• cpu-idle:
• wakeup:
• hotpath:
• allocation:
• gui-thread:
• race:
• deadlock:
• contention:
• lifecycle:
• native:
• delete:
• uncertain:

Priority:

• P0: confirmed race, deadlock, corruption risk, permanent hang, or runaway resource use.
• P1: confirmed leak, persistent idle CPU, repeated wakeup, major UI stall, or unbounded growth.
• P2: measurable hot path, excessive allocation, avoidable GUI-thread work, or significant memory reduction.
• P3: plausible issue requiring additional runtime evidence.

Do not bury confirmed issues inside general advice.

Required report

Start with:

verdict: PASS | FAIL | INCONCLUSIVE

Then report the baseline:

baseline: build=<configuration>; idle CPU avg=<x>; idle CPU peak=<x>; RSS=<x>; heap live bytes=<x>; memory slope=<x per cycle/minute>; threads=<x>; wakeups=<x>.

Then provide ranked findings.

Then provide:

coverage: <scenarios actually executed>.

limitations: <anything that could not be executed or proven>.

End with:

net: confirmed leaks=<N>; growth paths=<N>; races=<N>; deadlocks=<N>; idle recurring stacks=<N>; estimated removable steady-state RAM=<N MB or unknown>.

If no issues are found, do not merely say "looks good." Say:

Idle clean. Memory plateaus. No races or deadlocks reproduced. Ship.

Then list the exact coverage and measurements supporting that conclusion.

Final constraint

Do not fix anything during this audit.

Do not generate generic Qt/C++ performance advice.

Read the actual code, trace every relevant caller, execute available diagnostics, collect evidence, rank root causes, and stop.