Performance Tuning

The tools on this site split into two groups: CI/CD tools I use professionally, and personal tools I run myself on a laptop, phone, and a couple of small home devices. The tuning principles differ accordingly — CI/CD tuning is about not wasting compute at scale, while personal-tool tuning is about not making myself wait long enough to lose focus.

Jenkins (general principles)

• Cap executors to real capacity. Executors are a promise the controller makes about how much concurrent work it can schedule — oversubscribing them just causes context-switching between jobs, not more throughput.
• Prefer shallow clones where the job allows it — full-history checkouts are a common, easily-avoided source of slow job start times on repos with long histories.

See Bounding growth for how plugin sprawl and build-history retention are kept from becoming performance problems in the first place.

Concourse (general principles)

See Setup & Sizing for worker resource limits, garbage-collection tuning, and pipeline sizing — and Team-scoped workers for dedicating capacity per team once shared-pool contention becomes a recurring problem.

Obsidian (personal setup)

• Vault size and plugin count are the two levers that matter. Indexing and search slow down with both. A vault in the low thousands of notes with a lean plugin list stays snappy; heavier community plugins — especially ones that scan the whole vault on every keystroke — are the first thing to disable when things feel sluggish.
• Exclude large non-note folders from indexing (attachments, exported PDFs) via Obsidian’s file/folder exclusion settings — they don’t need to be searched as text.
• Disable plugins you’re not actively using rather than leaving them installed-but-idle. Installed plugins still load at startup even if their features go unused.

OmniFocus (personal setup)

• Keep the inbox near zero. Performance here is more about cognitive load than software speed — an inbox with hundreds of uncategorized items makes every perspective feel heavier than it is, encouraging avoidance instead of the intended lightweight capture-and-process loop.
• Archive completed projects rather than leaving them active-but-done; fewer active projects means faster, more trustworthy perspectives.

Homebridge (personal setup)

• Keep the plugin count deliberate. Each Homebridge plugin polls its device(s) on its own schedule; a large, unpruned plugin list is the most common cause of a sluggish HomeKit app or delayed accessory state.
• Split accessories across bridges if the count gets large. HomeKit has practical limits on accessories-per-bridge; child bridges keep one flaky plugin from taking down every other accessory’s responsiveness.
• Run it on stable, low-latency infrastructure (a Raspberry Pi or similar always-on device on wired or strong wifi) — Homebridge’s responsiveness is dominated by network latency to the devices it bridges, not CPU.

The general pattern

Whether it’s a CI system or a personal tool, the same three levers keep showing up: bound growth (prune history, archive completed work, exclude what doesn’t need indexing), limit concurrency to actual capacity (executors, worker resource caps, accessories per bridge), and keep the installed surface area small (plugins, jobs, pipelines). None of this requires more powerful hardware — it requires not letting any one of these tools accumulate cruft indefinitely.