Known Limitations

This page documents the main limitations, boundaries, and caveats of cPerformanceManager.

Windows-oriented design

The class is designed primarily for Windows-based Excel/VBA environments. API-backed timing methods depend on Windows APIs.

Not all timing methods are equally suitable for benchmarking

The class exposes multiple timing methods, but they are not all equally benchmark-worthy. Method 5 is the preferred benchmark path.

ElapsedTime is presentation-oriented

Use ElapsedSeconds for numeric logic and measurement comparisons.

Very small benchmarks are still difficult

Even with a good timing class, extremely tiny workloads remain hard to benchmark cleanly because the measured cost may be comparable to:

• VBA call overhead
• loop overhead
• class wrapper overhead
• Excel object-model overhead
• scheduler noise

Benchmark results are environment-sensitive

Results vary with workbook state, calculation state, system load, and Excel behavior.

Pause is a utility, not a precision scheduler

Pause is useful for demos, tests, and simple waits, but it is not a substitute for high-precision scheduling.

timeBeginPeriod(1) is system-affecting

Method 3 support may request 1 ms multimedia timer resolution. That affects system timer behavior more broadly than just the current class instance.

TW suppression depends on external shared support

TW behavior requires the supporting shared module. The class will not compile if the corresponding procedures are missing.

Checkpoint/reporting state is session-bound

Checkpoint data and run labels belong to the current timing session. A new StartTimer clears checkpoint/report state by design.

ReportAsText is developer-facing

ReportAsText is intended for readable diagnostics. Use ReportAsArray when you need a machine-readable export surface.