--- title: Computer feels slow? A step-by-step fix-it guide (free fixes first, new hardware last) (part 2) --- # Computer feels slow? A step-by-step fix-it guide (free fixes first, new hardware last) (part 2) ## What it is This is part 2 of the [Computer feels slow? A step-by-step fix-it guide (free fixes first, new hardware last)](slow-computer.md) page. It carries the next stretch of the material on that page, moved here because a single page is capped at 40,000 characters. ## Where to find it Reach this part through [Computer feels slow? A step-by-step fix-it guide (free fixes first, new hardware last)](slow-computer.md) — it lists every part and explains where the feature lives in the product. Everything below is reached from the same place. ## How it behaves Everything below is the behaviour, detail and edge cases that belong to this stretch of the Computer feels slow? A step-by-step fix-it guide (free fixes first, new hardware last) page. ### Tier 2 — Free, but needs a restart or a quick cleanup > **Running fewer sessions is never the fix.** Session and process _count_ is not what makes a machine crawl — a hundred running clean is the normal baseline, not the ceiling. If Omniscio freezes your computer under load, that is a **bug in Omniscio**, and shedding sessions only hides it: the freeze stops being reproducible and never gets fixed. Report it (bottom of this page) instead. The dials below pace the _starts_; they don't ask you to do less. 1. **Widen the start spacing (do this first if a burst is what hurts).** A machine usually tips over when many things start _in the same instant_, not from the amount of work. **Settings → Performance** gives you two spacing dials — **"Spacing between sessions when many restart at once"** and **"Wait between automation-created new sessions"** — so a big wave trickles in instead of landing all at once. Same work, no spike. Full explanation under [If RAM is fine but it freezes in bursts: a spawn storm](#if-ram-is-fine-but-it-freezes-in-bursts-a-spawn-storm) below. 2. **Relaunch Omniscio to pick up shipped speed-ups.** If you have been running the same build for a while, relaunching adopts every performance fix that has shipped since, and frees memory a long-running app or a just-disabled feature was still holding. Treat this as a _build refresh_, not a cure: **if a relaunch reliably makes a freeze go away, that is the bug reproducing** — please report it before it fades. 3. **Turn off background features you don't use, then restart.** Anything that scans files or polls on a timer adds constant load. If you don't use a feature, turn it off — and restart Omniscio afterward, because some features keep working until the next launch. 4. **Sweep abandoned project copies (developers / heavy multi-session users).** If you use Omniscio to run many coding sessions, leftover **git worktrees** — each with its own `node_modules` — can quietly pile up to _hundreds of gigabytes_ and get re-scanned forever by backup and antivirus software. Cleaning them up is one of the biggest wins for a developer machine. Omniscio already sweeps these in the background on a schedule; heavy users can tune how often (and whether it uses AI to judge which stalled copies are safe to remove) from the **Dev Pipeline** panel's **Setup** tab. On Windows, Omniscio also keeps these worktree folders out of the **Windows Search** index automatically — no administrator prompt — so the indexer never crawls every copy (a project kept in Documents used to make it crawl millions of files). Want one indexed anyway? Re-tick it in Windows' Indexing Options; Omniscio won't undo that. 5. **Reclaim space from Omniscio's own database (if it has grown huge).** Everything Omniscio remembers — your projects, sessions, and every message — lives in a single database file that only ever **grows**: deleting old chats leaves reusable empty space _inside_ the file rather than handing it back to your disk, so after heavy use it can sit at several gigabytes that are mostly empty. **Settings → Diagnostics → "Reclaim disk space"** clears cached chat layouts and schedules a one-time compaction that runs at your next restart (behind the splash) and physically shrinks the file — your conversations are untouched. This is Omniscio's own database; it's separate from the **git** repo cleanup some developers need further down. See [database-compaction.md](database-compaction.md). ### Advanced — Windows power-user cleanup _(optional)_ These genuinely help, but they touch system settings and need an **administrator "Yes" (UAC)**. If you're not comfortable, the easiest path is to **ask your Omniscio agent to do it for you** ("Please add a Defender exclusion for my Omniscio repo and explain what you changed") — the agent can read your current values and apply the change precisely. Or **skip them** — Tiers 1–2 above already do most of the work. > **You may not have to come looking for this.** If Omniscio freezes for a few seconds more than once **after it has finished starting up**, it raises an inbox card — **"The app froze more than once"** — and that card now names antivirus scanning as the usual cause and an exclusion as the fix. Its **Start session** button opens a session that checks your machine and walks you through it. The session **looks first and asks before changing any security setting**, so nothing is switched off behind your back. Fresh machines are the classic case: the scanner has never seen Omniscio's files, so it scans each one the first time Omniscio touches it, and a microsecond file write becomes a multi-second one. Freezes while Omniscio is still starting up (the loading screen is showing) never raise this card and never count toward it — a slow start is not the app freezing while you use it. - **Antivirus (Defender) exclusion** for a big dev repo + its worktrees, and Omniscio's data folder. Antivirus real-time-scanning the constant file churn can burn ~1 GB of RAM and real CPU. > **Contributing to Omniscio's own codebase? The Defender half is done for you.** Running `npm run setup` in the Omniscio repo excludes the repo, the worktree folder, Omniscio's data folder and the pnpm store from **Defender** — one administrator prompt the first time, none afterwards, and the repo's `SETUP.md` lists how to undo it. It skips the prompt entirely if you are not on Windows, have no terminal, or say no, and it never blocks the setup either way. **Windows Search needs nothing from setup:** the app keeps its own worktree folders out of the index for everyone (see step 4 above); to keep the repo itself out as well, untick it once by hand (Settings → Privacy & security → Searching Windows → Advanced Indexing Options → Modify). That's a contributor-only convenience; the manual steps below are what everyone else wants, and they apply to any project. In an **elevated** PowerShell: ```powershell # Use YOUR repo path; repeat for the Omniscio data folder if you wish Add-MpPreference -ExclusionPath "C:\path\to\your\repo" Add-MpPreference -ExclusionPath "$env:APPDATA\omniscio" # Also exclude the busy programs by NAME — stops the scanner inspecting every # file they open while running, including Omniscio writing to its own database: Add-MpPreference -ExclusionProcess "node.exe" Add-MpPreference -ExclusionProcess "git.exe" Add-MpPreference -ExclusionProcess "electron.exe" ``` Excluding the **folders** stops the files on disk from being scanned; excluding the **processes** stops the scanner from checking what those programs open while they run — which matters because Omniscio's own app (`electron.exe`) constantly writes to its database, and every one of those writes was being scanned. _(Also worth excluding the same folders from any cloud backup app — e.g. Backblaze — and from any file-search indexer that watches your drives (Windows Search, or third-party tools like Everything) — any of these can otherwise re-scan millions of tiny dependency files as they churn and sit at the top of your CPU or RAM usage.)_ - **Even better than the exclusion above: put your heavy file activity on a Windows 11 "Dev Drive."** A **Dev Drive** is a kind of drive built into Windows 11 for exactly this. On it, Microsoft Defender runs in **performance mode** — it scans files _after_ they're written instead of pausing every file operation to check it first, so you keep antivirus protection but lose the constant real-time-scan tax. That's a big win because Omniscio and the coding sessions it runs touch a huge number of small files. It's our own setup: Omniscio's repo, its package cache, and all its working copies live on a Dev Drive, so installs are fast and the file churn isn't scanned in your way. Put your **code projects, package caches, and git worktrees** on it (for Omniscio's **data folder** itself, the next bullet is the dedicated, reversible way to move it). **Don't** put Windows, your installed apps, or the Omniscio program itself on it — a Dev Drive is for the busy _data_, not the system. Two guardrails we learned the hard way: - **Size it generously and keep free space.** A nearly-full Dev Drive flips from a speed-up into a _new_ cause of freezes (it stalls on its own bookkeeping and every file operation waits on it) — make it large, and sweep abandoned worktrees (Tier 2.4 above) so it never fills. - **Put it on a fast SSD.** It only helps if the disk underneath is fast; moving your work onto a drive slower than your system drive can be a net loss. - **To create one** _(Windows 11 only)_: Settings → System → Storage → Advanced storage settings → Disks & volumes → **Create Dev Drive** (at least 50 GB — ideally much more). If the menu doesn't match your build, ask your Omniscio agent: _"Please set up a Windows Dev Drive for my code and explain what you changed."_ _(Performance mode is a Microsoft Defender feature; a third-party antivirus may still scan these files.)_ - **Watch for the Windows file cache ballooning** _(a ReFS Dev-Drive quirk worth knowing)_. Heavy file churn from many sessions can make **Windows' own file cache** swell to tens of gigabytes and push your **available RAM** toward zero — which then triggers the exact swap-thrash freezes at the top of this guide. The tell is unusual: your available memory is low **but your actual programs aren't using much** — it's nearly all "cached." Omniscio watches for this and raises an inbox alert (**"Windows file cache is crowding out memory"**) when it happens. A **restart** clears it immediately; if it keeps recurring, ask your Omniscio agent: _"My available RAM keeps disappearing into the Windows file cache — please cap the Windows system file cache so it can't balloon."_ (The agent installs a size cap so the cache can never crowd out your apps.) - **Move Omniscio's data folder to a drive nothing else is hammering.** This fixes one very specific — and very annoying — pattern: **only Omniscio gets slow** (scrolling stutters, typing lags, switching chats takes seconds) **while the rest of your computer feels fine**, and it is worst exactly when your machine is doing heavy file work — builds, big downloads, or many coding sessions churning files. What's happening: Omniscio keeps everything it knows in a database on one disk, and when other software hammers that same **physical disk**, every read Omniscio needs waits in line behind it. Two things make this sneaky: drive letters can lie (two letters — say `C:` and `K:` — are often partitions of **one physical disk**, so "my projects are on a different drive" may not actually be true), and under sustained disk traffic Windows also evicts Omniscio's in-memory database cache, forcing the app to re-read from the busy disk at the worst possible moment. The fix is to give Omniscio's data a quiet home of its own. **The safe way is to ask your Omniscio agent** — paste this into any session: _"Omniscio gets slow while the rest of my computer is fine, especially during heavy file work — please check whether Omniscio's data folder shares a physical disk with the busy work, and if so move it to a quieter internal SSD. Copy, don't move, so the original stays as a fallback, and walk me through the restart."_ For reference, what the agent (or a comfortable power user) actually does: **quit Omniscio**; **copy — don't move —** the whole data folder `%APPDATA%\omniscio` to a folder on the quiet drive (say `H:\AMC-Data\agent-mission-control`); set the user environment variable `DATA_DIR` to that new path; start Omniscio again **from a new terminal or shortcut** (windows opened before the change still carry the old setting). Two guardrails: pick an **internal SSD that nothing busy touches** — not the drive your projects, worktrees, or downloads churn on, and not a USB drive — and always **copy**, so the original folder stays intact as an instant fallback. **Undo any time:** quit Omniscio, delete the `DATA_DIR` variable, start it again (again from a new window) — you're back on the original folder exactly as it was. One scare to know about in advance: if Omniscio ever opens looking **brand-new** (empty, no sessions), the variable is pointing at a wrong or empty folder — nothing is lost; quit, fix or delete the variable, and relaunch. - **Still Defender after all that? It's Behavior Monitoring, not file scanning — the one part exclusions can't fix.** If you've done the exclusions above (and maybe moved work to a Dev Drive) and Defender — shown as **"Antimalware Service Executable"** (`MsMpEng`) in Task Manager — is _still_ near the top of your CPU, the cause isn't files being scanned anymore. It's **Behavior Monitoring**: the part of Defender that watches how your _running programs_ behave, which folder and process exclusions do **not** turn off. On a machine running a swarm of Omniscio sessions it watches every one, so it keeps costing CPU no matter how much you exclude. Two things make it stubborn: it can only be changed while **Tamper Protection** is turned off (with Tamper Protection on, the setting silently flips back), and turning it down is a real security trade-off. The safe way is to **let your Omniscio agent do it** — say _"Defender is still my top CPU user even after exclusions — please turn off Behavior Monitoring but keep real-time file protection on."_ The agent turns Tamper Protection off, disables **only** the behavior engine (your real-time file/malware scanning stays **on**), and can lock the setting so a Windows update doesn't quietly switch it back. It's fully reversible. _(You keep protection against known malware in your files; you give up Defender's guesses about suspicious behavior — usually a fair trade on a busy dev machine, and your agent will explain it before making the change.)_ > **Contributing to Omniscio? There is a command for this.** `npm run harden:windows` does the whole thing in one administrator prompt: turns Defender's real-time scanning off at the **policy** level, and stops Windows Update restarting your machine on its own. Undo it with `npm run harden:windows -- --revert`. It is **opt-in and never part of `npm run setup`** — this is a much wider trade-off than a folder exclusion, so nobody's machine gets it without asking. > > It exists because the obvious ways do not stick. Turning Defender off in the Windows Security app, or with `Set-MpPreference`, is **designed to be temporary** — Windows silently switches it back on after a while and again at every reboot, which is why re-clicking the toggle never works. Only the Group Policy form persists, and only while **Tamper Protection** is off. A Windows _feature_ update can still reset it, so the command also installs a small task that re-applies the setting at every boot. - **Cap the Windows pagefile so it can't fill your system drive.** _Only_ if the scan showed a growable ("system-managed") pagefile **and** your system drive is filling up. Pick a fixed size **at least as large as your RAM** (too small risks out-of-memory crashes). In an **elevated** PowerShell (example pins it to 32 GB — adjust to your machine): ```powershell $pf = Get-CimInstance Win32_PageFileSetting -Filter "name='c:\pagefile.sys'" $pf | Set-CimInstance -Property @{ InitialSize = 32768; MaximumSize = 32768 } # MB ``` - **Raise the Windows desktop-heap limit** _(the most advanced — best left to your agent)_. On a machine launching _hundreds_ of processes, Windows can hit a built-in ceiling and refuse to start new ones, which looks like a stall. The fix raises one registry value and needs a **reboot**. The safest way is to ask your Omniscio agent: _"Please raise my Windows desktop heap to 64 MB and tell me exactly what you changed."_ For reference, the value lives at `HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems` → the `Windows` entry → the `SharedSection=1024,20480,768` part, where the middle number (desktop heap in KB) is raised (e.g. `20480` → `65536`). Mistyping this can stop Windows from booting — let the agent do it, or skip it. --- ### If RAM is fine but it still freezes: a stuck Windows service If the Step 0 checks show **plenty of free RAM** yet the machine still freezes — and the CPU sits pinned near 100% doing **"kernel/system"** work rather than your own apps — the usual cause is a **Windows background service stuck in a loop.** A couple of Microsoft's own _optional_ services are the known offenders: **whesvc** ("Windows Health and Optimized Experiences") and **webthreatdefsvc** ("Web Threat Defense"). When one wedges, it spins furiously — hundreds of thousands to millions of tiny CPU hand-offs a second — while using almost none of its _own_ CPU. Running at normal priority, it crowds your window off the processor and the whole machine hitches, no matter how much RAM you have. **How to spot it:** the Step 0 "stuck service" check shows **one `svchost` generating far more CPU hand-offs than anything else**, the thread queue is very high, and disk and RAM are both fine. **The fix — let your Omniscio agent do it.** Open any session and say: _"My computer keeps freezing but RAM is fine — please find the stuck Windows service and fix it."_ The agent can pinpoint exactly which service is spinning and **restart** it (that clears the wedge instantly, no reboot). If it turns out to be a **non-essential** service like `whesvc` — optional health telemetry that nothing else depends on — the agent can **disable** it so it can't come back. A protected Defender service like `webthreatdefsvc` (which powers Windows' Enhanced Phishing Protection) can't be _disabled_ the usual way, and just restarting it clears the spin only until it wedges again. There's still a durable fix: **turn that feature off by policy** — the service then goes idle and stops on its own, usually within a minute, no reboot needed. The trade-off is losing Windows' phishing-site and password-reuse warnings, so it's a small security choice your agent will flag before making it. **Don't disable a service by hand on a guess** — let the agent confirm which one it is first, so you never switch off something Windows actually needs. **One reason a stuck service can hide for a long time:** it may spin in _bursts_ — hundreds of thousands of tiny CPU hand-offs one second, almost none the next — so a single quick sample can look calm and miss it. The reliable tell is the Step 0 check seen **across several looks**: one `svchost` generating far more CPU hand-offs than everything else. For reference, the durable off-switch an agent applies for `webthreatdefsvc` — turning off Windows' Enhanced Phishing Protection so the wedged service goes idle — is, in an **elevated** PowerShell: ```powershell $k = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WTDS\Components' New-Item -Path $k -Force | Out-Null # Turn off Enhanced Phishing Protection (what webthreatdefsvc powers); it then goes idle: 'ServiceEnabled','NotifyMalicious','NotifyPasswordReuse','NotifyUnsafeApp','CaptureThreatWindow' | ForEach-Object { Set-ItemProperty -Path $k -Name $_ -Value 0 -Type DWord } ``` --- ### If RAM is fine but one DRIVE is pinned: a Windows file-crawler A third variation, and the one most likely to bite you if you keep **a lot of project folders** on one drive. RAM is fine, the CPU is fine, and **most of your drives are idle — but one of them is completely jammed**, and everything hitches whenever an app touches that drive. The usual culprit is **`InventorySvc`** ("Inventory and Compatibility Appraisal service"), a Windows telemetry component that periodically walks your disks cataloguing installed software. On an ordinary PC you'd never notice. But every developer project folder carries its own `node_modules` (or equivalent) holding tens of thousands of small files, so if you keep dozens or hundreds of them, that crawl becomes **millions of files** — and it will grind that drive continuously. **How to spot it:** the tell is a **split** — one drive at ~0% idle with a long queue of waiting requests, while your other drives sit near 100% idle. That asymmetry is the whole diagnosis: a genuinely overloaded machine slows everything down; a crawler pins exactly one drive. **Measured on a real developer machine (2026-09-02).** With 263 project folders on one drive, `InventorySvc` was the single biggest disk user on the box at **~40,000–75,000 file operations per second** — an order of magnitude above any real application. That drive sat at a queue depth of **96 with 0% idle** while every other drive was 65–100% idle. Turning the service off moved that same drive to a queue of **0.6 and 56% idle**, and the app's worst-case delay dropped by about 40%. **The fix — let your Omniscio agent do it.** Open any session and say: _"One of my drives is pinned but RAM and CPU are fine — please check whether a Windows crawler is hammering it."_ The agent confirms which process it actually is **by process ID** before touching anything, then stops and disables it. Nothing you use depends on this service: it does **not** serve Windows Update, security, or any app-compatibility behavior you'd notice. For reference, in an **elevated** PowerShell: ```powershell # Confirm it is really the culprit FIRST — never disable a service on a guess: Get-CimInstance Win32_Service -Filter "Name='InventorySvc'" | Select-Object Name, State, ProcessId # Then stop it and keep it from coming back: Stop-Service -Name InventorySvc -Force Set-Service -Name InventorySvc -StartupType Disabled ``` To undo it at any time: `Set-Service -Name InventorySvc -StartupType Automatic` then `Start-Service -Name InventorySvc`. **Can it turn itself back on?** Essentially no — but check after a big Windows version upgrade. Once it is set to Disabled, Windows writes that to the registry and honors it across reboots; the service also registers **no start triggers**, so nothing else can wake it on demand, and its automatic-restart-on-crash setting can't apply to a service that is never allowed to start. The one realistic exception is a **Windows feature update** (a version upgrade, not the monthly patches), which reinstalls system components and can reset service settings to their defaults — as can a repair such as `sfc /scannow` or a DISM restore. So it will not come back on its own, but it is worth re-checking after a version upgrade. The Step 0 scan above includes that check, so any future "my computer feels slow" pass catches it automatically. **Related, and worth doing anyway:** fewer project folders means less for any crawler (and your own tools) to walk — see **Tier 2** on sweeping finished worktrees. --- ### If RAM is fine but it freezes in bursts: a spawn storm A close cousin of the stuck-service case above, with a different signature. Here the machine freezes for a few seconds to a minute and **recovers on its own**, RAM is fine, and **no single process** is the hog — and it tends to hit right when **a lot of work starts at once**: a batch of builds/tests, a CI run, or many sessions kicking off jobs at the same moment. Afterwards nothing looks wrong, which is what makes it maddening. This is a **spawn storm** (a "runnable-thread stampede"): dozens of **short-lived** helper processes get created in the same instant, and creating that many at once floods the Windows scheduler so hard that even your window can't get a turn — so the whole machine stalls until the burst drains. The tell is different from a stuck service: instead of one `svchost` pinned, it's a sharp jump in the **number of running processes** right at the freeze, and the little processes vanish within a second or two — so by the time you look, the evidence is gone. **Why it hides:** ordinary tools sample every few seconds and miss anything born-and-died between samples; during the freeze the sampler is starved too. The reliable way to catch it is to record **every process the moment it is created** and read it back after the freeze. **The fix — let your Omniscio agent do it.** Open any session and say: _"My computer keeps freezing in short bursts but RAM is fine — please turn on process-creation auditing, wait for the next freeze, and tell me what is spawning the burst."_ The agent switches on Windows' process-creation log (Event 4688, which stamps every process at birth with its parent and full command line), waits for the freeze, then **groups the burst by parent** — the one parent that spawned dozens of children is what fanned out, and its children's command lines name the exact job. For reference, the developer commands (an **elevated** PowerShell) are: ```powershell # Arm: record every process creation, with its command line reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f auditpol /set /subcategory:"Process Creation" /success:enable # ...after the next freeze, read that burst grouped by parent (last ~3 minutes shown): $ev = Get-WinEvent -FilterHashtable @{ LogName='Security'; Id=4688; StartTime=(Get-Date).AddMinutes(-3) } $ev | ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data | Where-Object Name -eq 'ParentProcessName' } | Group-Object '#text' | Sort-Object Count -Descending | Select-Object Count, Name -First 10 # Disarm afterwards (it is verbose): auditpol /set /subcategory:"Process Creation" /success:disable ``` **The real fix is usually to pace the starts, not to run less.** When a burst is real, the cure is spacing those job _starts_ a fraction of a second apart instead of letting them all launch in the same instant — the same amount of work, no spike. Omniscio already does this for its own heavy background jobs (builds/tests/lint) through its [job pacer](heavy-job-pacing.md), so a swarm of sessions can't stampede your machine. On developer machines Omniscio also paces what the **agents themselves** launch: their searches and their `npm`/`npx`/`pnpm` job starts are spaced out automatically, the spacing widens as the machine heats up, and at storm-level CPU new launches briefly **hold** so the machine drains instead of tipping over. Agent recursive `grep` and `find` also automatically **skip the heavy folders** (`node_modules`, the worktree piles, build output), so one careless search can't walk millions of dependency files and spike the disk — and that protection is built in and self-repairing, so it can't be silently lost. Dependency **installs** go one step further: an agent's `npm install` / `pnpm install` now **takes a turn through a shared "install slot,"** so only one install writes to the shared package store at a time instead of a dozen agents all unpacking packages onto the disk at once — one of the heaviest disk bursts a swarm of sessions can create (it's the same one-at-a-time rule Omniscio already uses for its own project-setup work). A busy machine may make an install wait for its turn. If exclusive admission cannot be proven before the safety deadline, that install is **refused and can be retried later**; it never proceeds beside another store writer. This protects dependency integrity and slows agent work rather than the Omniscio window. And when the box is genuinely overloaded, an agent's **heavy one-off commands** — a typecheck, a test run, a build, an unusual search tool, or a tool launched by its full path — are briefly **held until the machine cools** (bounded, then always allowed), so a big job can't launch straight into a freeze; this catches the odd shapes the automatic pacing above can't see. And for the **session starts themselves** — the wave when many come back after an app restart or a rate-limit recovery, or when you restart a whole batch at once — **Settings → Performance** gives you two spacing dials: **"Spacing between sessions when many restart at once"** and **"Wait between automation-created new sessions."** Each defaults to Omniscio's current timing; widen it so a big wave of starts trickles in instead of landing all at once (set either to **0** to turn its spacing off). Sessions you start or restart by hand, one at a time, are never delayed. If you are a developer whose _own_ tooling causes the storm, cap the **rate** things start, not just how many run at once. --- **Alt+Tab protection is automatic on Windows.** When every Omniscio window loses focus, the app immediately moves its running agent process trees to Windows' strongest background-yielding CPU priority. The application you switched to gets first claim on the processor while all sessions keep running; focusing any Omniscio window restores their normal priority immediately. There is no setting to manage and no session-count limit involved. --- ## Related The overview, the other parts, and everything else worth reading next all sit on [Computer feels slow? A step-by-step fix-it guide (free fixes first, new hardware last)](slow-computer.md).