Performance

Stack Trace Defaults and Performance

Understand ordinary log stack defaults, full-stack diagnostics, cache warmup, and the setting that controls AzCon.Log capture.

Stack trace defaults
Performance tradeoffs
Extreme logging rates
Cold runs and cache warmup
Log Stack Trace Capture setting

Stack Trace Defaults

AzCon.Log is optimized for high-volume everyday logging. By default, ordinary log entries capture the source file and line number without walking the full call stack.

Use the APIs this way:

AzCon.Log("Inventory count changed");     // File and line by default
AzCon.Debug("Inventory audit details");   // Full stack trace by default
AzCon.LogWarning("Inventory mismatch");   // Full stack trace by default
AzCon.LogError("Inventory save failed");  // Full stack trace by default

By default, warnings and errors keep full stack traces because they are usually investigation entry points. AzCon.Debug is the intended choice when you want a full diagnostic stack for non-warning, non-error logs.

Why Log Defaults To File And Line

File-and-line capture keeps the common path fast. In the current controlled benchmark profile, warm AzCon.Log calls in file-and-line mode measured about 2x faster than UnityEngine.Debug.Log, with 0 B/call measured managed allocation on the logging thread. Treat that as benchmark-specific guidance, not a universal runtime guarantee; string construction, sinks, project settings, editor state, hardware, and Unity version can change results.

Full stack capture is intentionally richer and more expensive. With full stack traces, Ben.Demystifier support, and stack/source syntax-highlighted presentation enabled, AzCon performs substantially more diagnostic work: capturing, storing, formatting, resolving source context, and preparing readable stack/source output. In the same benchmark family, that heavier path measured about 0.5x the throughput of Unity logging.

That tradeoff is deliberate: ordinary AzCon.Log defaults to file and line for fast everyday logging, while AzCon.Debug, warnings, and errors default to full stack traces for deeper debugging.

Extreme Logging Rates

Azkar Console is built for production-minded performance, not unbounded logging at any cost.

Thousands of logs per frame are treated as a backpressure scenario. Text logs usually keep up better because they are cheap to append. The Azkar database format does more structured work, so the normal asynchronous database sink may drop older queued entries and write a dropped-log marker under extreme bursts. Crash Forensics writes synchronously for stronger recovery behavior, but it is not an unbounded logging mode.

Use normal asynchronous durability for everyday development. Use Crash Forensics when investigating crashes, corruption, CI failures, or other cases where blocking is acceptable and database recovery matters more than throughput.

Cold Runs And Cache Warmup

The first cold run will usually be slower. Caches start empty, so Azkar Console has to resolve callsites, stack frames, source paths, and highlighted source/stack text for the first time.

After the first run, cache reuse improves performance for repeated callsites and repeated source previews.

Changing The Behavior

To change how ordinary AzCon.Log captures stack information, open Window > Azkar Console > Settings > Log Details & Readability > Stack Traces > Log Stack Trace Capture.

Option	Behavior
`File and line`	Default. Captures the log callsite without a full stack walk.
`Full stack trace`	Makes ordinary `AzCon.Log` capture a full call stack.