Benchmark SplitContainer repaint performance and resource stability

[KlausLoeffelmann]

Objective

Create a reproducible benchmark and stress harness that quantifies splitter-movement cost and detects memory or resource leaks during heavy resize/redraw activity.

Measurements

Capture before/after numbers for:

• Interaction or iteration throughput.
• Elapsed time and CPU usage.
• Managed allocations and retained managed memory after forced collection and stabilization.
• Process working set and private bytes.
• GDI and USER object counts.
• Window/control handle counts where available.
• Layout, invalidation, and paint frequency when measurable without distorting results.
• Responsiveness under light, medium, and deeply nested heavy panel payloads.

Method

• Automate repeated splitter movement across a fixed range in both orientations.
• Include warm-up, measurement, and post-run stabilization phases.
• Use enough iterations and duration to reveal monotonic growth.
• Separate one-time caches from sustained leaks.
• Compare the baseline and proposed implementation on the same machine and configuration.
• Record runtime, architecture, visual mode, theme, payload, build configuration, iteration count, and machine details.
• Prefer existing repository benchmark/test infrastructure. If a formal microbenchmark would misrepresent UI behavior, use a deterministic stress harness and document why.

Completion criteria

• The methodology is reproducible and checked into an appropriate test or benchmark location.
• Baseline and fixed-build numbers are recorded.
• Light, medium, and heavy payloads are measured.
• No sustained managed/native memory, GDI/User object, or handle growth is observed.
• CPU and responsiveness costs are quantified and judged acceptable.
• Any measurement limitations or expected one-time caching effects are documented.