Performance & Hardware
The Performance & Hardware tab is the one you probably won’t visit unless something is wrong. Ishvana’s default performance configuration is tuned for consumer hardware — a typical laptop or desktop from the last five years handles everything out of the box without tweaks. The detected hardware tier picks reasonable defaults for cache sizes, thread pool counts, and memory limits. Most users should never need to touch any of it. But the knobs exist for the users who do need them: authors with unusual hardware (very modest laptops, very high-end workstations, unusual GPU configurations), authors working with exceptionally large projects that stress the default limits, or authors troubleshooting specific slowness that the defaults didn’t anticipate. This tab is where those users find the knobs. This page is the reference for what each one does.
Hardware tier (read-only)
Section titled “Hardware tier (read-only)”At the top of the tab, a read-only display shows the hardware tier Ishvana detected for your machine:
- High-end. GPU + 16 GB+ RAM + 8+ CPU cores. Maximum optimization enabled.
- Balanced. 16 GB+ RAM + 6+ CPU cores, no GPU. High optimization.
- Standard. Moderate RAM and cores. Conservative defaults.
- Basic. Below standard. Minimal concurrency, small caches.
The tier was picked at startup by the hardware detection service. It’s not user-configurable — the detection is considered authoritative, and forcing a different tier would be a way to give yourself bad defaults.
Below the tier label, a summary of detected hardware:
- CPU cores and threads.
- Total RAM.
- Available RAM (at detection time).
- GPU name (if detected).
- GPU VRAM (if detected).
- Platform and architecture.
This information is what the tier was computed from. If you think the detection was wrong — say, you have a GPU but it’s not being detected — the GPU probe section below lets you re-test.
GPU probe
Section titled “GPU probe”A section dedicated to GPU detection. Shows the current GPU status:
- Pass. GPU detected and usable for acceleration.
- Fail. GPU detected but the probe failed — might be a driver issue, might be a compatibility problem.
- Unavailable. No GPU detected.
- Crash. The probe crashed before completing. Something went wrong inside the detection code itself, usually because of a driver issue.
A Retest button runs the GPU probe again on demand. Useful after installing or updating GPU drivers, or after fixing a driver issue. The probe runs quickly — usually under a second — and updates the status immediately.
Why the GPU status matters: certain subsystems (the local embedding model, future local LLM features) can use the GPU if one is available. Without a GPU, they fall back to CPU, which works but is slower. A detected GPU that the probe says is “pass” means those subsystems are GPU-accelerated. A detected GPU that says “fail” means you’re running on CPU despite having capable hardware, and a driver fix would restore the acceleration.
Alert thresholds
Section titled “Alert thresholds”Two numeric fields that control when Ishvana warns you about resource pressure:
- CPU alert threshold. A percentage from 50-100. When sustained CPU usage exceeds this percentage, Ishvana flags it in the Analysis workspace. Default: 85%.
- Memory alert threshold. A percentage from 50-100. When sustained memory usage exceeds this percentage, Ishvana flags it. Default: 80%.
The alerts are diagnostic, not reactive. Hitting the threshold doesn’t make Ishvana do anything automatically — it just shows the pressure state in the performance dashboard. If the alerts fire frequently, it’s a signal that your workload is too heavy for the tier you’re on, or that a background service is misbehaving.
Lower the thresholds if you want earlier warnings. Raise them if the defaults are too noisy for your specific setup.
Bottleneck detection
Section titled “Bottleneck detection”A toggle: enable bottleneck detection (on/off).
When on, Ishvana’s performance intelligence subsystem periodically analyzes recent operations for patterns that suggest bottlenecks — a specific database query taking too long, an LLM operation hitting timeouts consistently, a cache that’s evicting more than it should. Detected bottlenecks are surfaced as optimization recommendations in the Analysis workspace.
When off, the subsystem doesn’t run. No recommendations are generated.
Default: On.
The bottleneck detection is a background job that runs on a heartbeat. Its cost is negligible for most workflows. Turn it off only if you have a specific complaint about startup time or background CPU usage that you’ve traced to this subsystem.
Cache size
Section titled “Cache size”A slider or numeric input that controls the maximum size of the in-memory cache in megabytes. The range is 100 MB to the full amount of your RAM, but in practice useful values are 256 MB to 2048 MB.
Default: tied to hardware tier. High-end gets 1024 MB. Balanced gets 768 MB. Standard gets 512 MB. Basic gets 256 MB.
Raise the cache size if you have a large project whose working set exceeds the default limit — you’ll see cache eviction happen frequently and want to hold more in memory. Lower it if you’re on a memory-constrained machine and Ishvana is using more RAM than you have to spare.
Changes take effect immediately — no restart needed. The cache starts evicting entries if the new limit is lower than the current cache contents; it accepts more entries without issue if the new limit is higher.
Cache TTL
Section titled “Cache TTL”A numeric field in seconds or minutes controlling how long cached entries stay valid before being considered stale.
Default: 30 minutes.
A shorter TTL means cache misses happen more often (the cache is thrown out faster) but you never see stale data. A longer TTL means cache hits are more common (better performance) but you might see slightly outdated data if the underlying state changes in a way the cache didn’t notice.
For Ishvana’s workflows, 30 minutes is a reasonable default because scope-aware invalidation catches most “data changed” scenarios proactively and the TTL is mostly a safety net for changes the invalidator missed.
Metrics retention
Section titled “Metrics retention”A duration setting for how long historical performance metrics are kept in the database. Default: 90 days.
Short retention (e.g., 7 days) means the performance history in Analysis is limited but the metrics database stays small. Long retention (e.g., 365 days) gives you a full year of performance history for trend analysis but the database grows accordingly.
Adjust if you want the Analysis workspace’s performance views to show more or less history.
Undo depth
Section titled “Undo depth”A numeric field for how many undo steps the editor keeps in memory per document. Default: 200.
A higher undo depth gives you more Ctrl+Z history but uses more memory per open document. A lower depth saves memory but limits how far back you can undo.
For most users, 200 is more than enough — you rarely need to undo more than a few dozen steps in practice. Lower it to 50 if you’re on a tight memory budget; raise it to 1000 if you’re doing heavy editing sessions and want deep undo.
Toast duration
Section titled “Toast duration”A numeric field in milliseconds controlling how long non-error notifications stay visible before auto-dismissing. Default: 3000 ms (3 seconds).
Lower if the toasts feel too lingering. Raise if they disappear before you can read them.
Error toasts have their own longer duration (usually 10 seconds) because errors actually need to be read. Toast duration only affects info-level notifications.
Thread pool size (advanced)
Section titled “Thread pool size (advanced)”A numeric field for the size of the backend thread pool. Controlled by hardware tier by default, but can be manually overridden.
Lower values mean less parallelism but less memory and CPU pressure. Higher values mean more parallelism but more resource consumption.
Default: tied to tier. High-end: 16. Balanced: 8. Standard: 4. Basic: 2.
Most users should leave this alone. The tier defaults are well-tuned. The only reason to override is if you have a very specific workload — a lot of parallel ML work, or a server-class machine where you want to use more threads than the tier default assumes.
What the tab doesn’t include
Section titled “What the tab doesn’t include”- LLM cost budgets. Those are on the Models tab.
- Network-related settings. Request timeouts, retry policies, proxy configuration. These aren’t user-configurable — Ishvana picks sensible defaults and doesn’t expose them.
- File system paths. The data directory location is an environment variable (
ISHVANA_DATA_DIR), not a setting. Change it by editing the environment, not by visiting Settings.