TOVIO feels slow

Large repositories, and the things actually worth tuning.

Written By Dustin

Last updated 17 minutes ago

Measure first

Establish which operation is slow — status, log, sync, or a build. They have different causes and the fixes do not overlap.

Slow status on a large tree

Auto-snapshot walks the working copy. The usual cause is tracking files that should be ignored — a node_modules or build directory with no .tovioignore entry can dominate everything else.

tovio status

Repository size

tovio gc --dry-runtovio gc --repacktovio gc --aggressive

--repack is the usual win. gc is undo-safe and will not collect what the op-log still needs, so --dry-run first is informative rather than obligatory.

Slow clone or sync

Clone less. The three modes:

tovio clone <remote> <repo> <dir> --blob-limit 1000000tovio clone <remote> <repo> <dir> --sparse 'src/**'tovio clone <remote> <repo> <dir> --depth 50

--blob-limit takes a size in bytes and omits file content larger than it, backfilling on read. It is usually the biggest single improvement on a repository with large binaries.

These do not combine freely. --sparse is a path scope and the others are content filters, so --sparse conflicts with --blob-limit, --blobless, --depth, and --no-attachments; --blob-limit and --blobless also conflict with each other. Combining them is refused up front rather than silently letting one win. Pick the one that matches your problem: --sparse for "I only work in one directory", --blob-limit for "the binaries are the problem", --depth for "the history is the problem".

The two kinds behave differently afterwards, and it matters. --blob-limit, --blobless, --depth, and --no-attachments are content filters: they make the clone promisor-backed, so reads that need omitted content backfill on demand and fail with TVO-SYNC-005 when the remote cannot serve them. tovio fetch --complete fattens such a clone back to whole.

--sparse is a path scope, not a filter. A sparse clone is not promisor-backed and fetch --complete will tell you the repository is already complete. Widen the cone instead:

tovio sparse listtovio sparse add <dir>tovio sparse clear      # back to a full checkouttovio sparse checkout   # materialize the new cone

Chunking

tovio policy chunking --min <n> --average <n> --max <n>

Tunes content-defined chunking. Worth touching only if you have measured and know what you are targeting — it changes how content is addressed.

Scale evidence is open

Behaviour at the declared ceilings is not yet proven. A performance problem on a large repository is genuinely useful to report.

Reporting it

Which command, roughly how long, and repository shape — order of magnitude for file count, commit count, and largest file. No paths, no names, no file listings.