dsh performance triage: startup, panels and models

"DeepSeek Harness is slow" usually mixes three layers: startup, panel response, and model latency. Separating them is faster than reinstalling or disabling everything.

Three layers

Measure each with its own signal.

A slow first token with a responsive UI points to model or network; a responsive model with laggy panels points to the client. Mixing them leads to upgrading or reinstalling. Measure once before changing; without a baseline, no result is attributable.

Startup

Startup time is easiest to measure: time from launch to usable.

1. Record startup with the current plugin set for several runs.
2. Disable groups of plugins, not all at once.
3. Compare startup after each group.
4. Check cache and disk state.
5. Confirm improvement over several runs, not one.

Plugin quantity is not the only factor; startup hooks matter, and cold start differs from warm start. A few plugins injecting at startup can cost more than many inert ones; comparing the first launch with later ones mixes cache effects.

Panel and rendering

Panel lag is usually style or script plugins.

1. Notice which operations lag: opening sessions, switching categories, scrolling.
2. Disable style and animation plugins first.
3. Compare page response.
4. Check long lists and large images.
5. Confirm the improvement persists.

Video wallpapers, particles, and complex sidebars are common causes, and browser cache or extensions interfere too. They block rendering; switching to static or disabling reduces load. Test in a clean browser profile before blaming DSH.

Model and network

Slow replies may have nothing to do with the client.

1. Measure time to first token.
2. Switch models or providers and compare.
3. Check network latency and proxy.
4. Check rate limiting and quota.
5. Compare a short and a long session.

A slow first token means waiting for the model, not rendering, and long sessions add load. Switching plugins wastes time; measure model and network. A new session comparison separates session effects from model effects.

Disable and compare

The most reliable method, with strict controls.

1. Record a baseline: startup, panel response, first token.
2. Disable half the plugins and retest.
3. Narrow the problematic half.
4. Confirm with a single plugin.
5. Restore and replace or remove.

Change only one variable at a time; disabling plugins while upgrading confuses the result. Half-splitting is faster than one by one: ten plugins need about four rounds, not ten.

Measure

Record numbers; "feels faster" is not evidence.

1. Startup: three runs, take the median.
2. Panel: repeat the same operation three times.
3. Model: same prompt, same model, compare first token.
4. Environment: version, plugin list, machine state.
5. Changes: what changed, when, result.

Medians reduce noise, and the environment matters. Single measurements vary with disk, network, and load. Without version and plugin list, numbers cannot explain.

Common misjudgments

Four frequent wrong conclusions.

1. "Reinstalling fixes it." Path and permissions may reset, but plugins and data remain; the cause may return.
2. "Upgrading is always faster." Versions differ; unmeasured upgrades may be slower.
3. "More plugins mean slower." Depends on hooks, not count.
4. "Slow means the model is bad." First token latency also includes network and quota.

All four skip measurement. Numbers first, conclusions second.

Order of action

Measure, isolate, replace, then upgrade.

1. Record baseline.
2. Isolate by layer.
3. Disable suspects in groups.
4. Replace or remove confirmed plugins.
5. Upgrade only when version is confirmed as the cause.

Upgrading is last because it changes many variables. It may fix things but makes attribution harder.

Next steps

Separate layers, measure, isolate. For plugin load failures, read What breaks after a plugin update. For output limits, read Output token limit and truncated replies. For quota issues, read request quota exhausted.

Sources: DeepSeek Harness docs, dsh CLI README, deepseek-harness repository