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

By default, AzCon.Log captures the source file and line number without walking the full call stack. This performs less work than full-stack capture, but actual cost still depends on log rate, message construction, enabled sinks, storage settings, platform, and project workload. Measure representative builds when logging volume matters.

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 diagnostic 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 records the callsite without walking and storing the full call stack. It therefore performs less work than full-stack capture.

Full-stack capture collects and stores the stack. When an entry is displayed, optional demystification, source resolution, and syntax highlighting can add presentation work. The cost depends on the Unity version, hardware, project configuration, message construction, enabled sinks, and editor state. Measure both modes in the target project when logging overhead is material.

Ordinary AzCon.Log therefore defaults to file and line, while AzCon.Debug, warnings, and errors default to full stack traces.

Extreme Logging Rates

Azkar Console uses bounded queues. It does not provide unlimited buffering for sustained log production that exceeds sink throughput.

Thousands of logs per frame are a backpressure scenario. When an asynchronous sink cannot keep up, it may drop older queued entries and write a dropped-log marker. The database sink also performs structured page writes. 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 Industries > 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.