Performance & Parallelism

Performance & Parallelism

Scanning speed is dominated by how fast files can be read and decoded. VDF splits its concurrency controls into three settings (all under Settings > Scanning) because storage and CPU want very different things.

The three worker settings

Parallel workers

How many files are processed at once, shared across all fast drives (SSDs).

• -1 = one worker per CPU core (recommended)
• 1 = strictly one file at a time (lowest system impact; also disables the per-drive logic below)
• any other value = a fixed global budget

Parallel files per hard disk

A separate, per-drive cap for slow drives: spinning hard disks, network shares, and drives that could not be classified. Default: 2.

A single spinning disk wastes most of its time seeking when many files are read from it in parallel, so throwing 16 workers at it makes the scan slower, not faster. With this setting, each slow drive is limited to a couple of concurrent reads while SSDs still use the full worker budget. Slow drives get their cap on top of the global budget, since they are seek-bound rather than CPU-bound.

Matching worker threads

CPU workers for the comparison phases (visual matching, partial clip matching). This is separate from the read settings above because comparison is pure CPU work with no storage involved. Default: 0 = automatic, which uses most of the machine while keeping a core or two free so the UI stays responsive.

How drives are classified

At scan start, every drive that holds files to scan is classified as SSD (fast) or HDD (slow):

1. User override - always wins (see below)
2. Network shares (UNC paths and drives the OS reports as network) count as HDD
3. Seek-latency probe - VDF performs a few random reads on one file per drive; SSDs answer in well under a millisecond, spinning disks need a head seek. Drives that cannot be probed are conservatively treated as HDD.

The scanning screen shows a progress bar per drive with its SSD/HDD chip, so you can see how each drive was classified and how it is progressing.

Correcting a wrongly classified drive

The probe can be fooled, most commonly when the probed file happens to sit in the OS page cache and a spinning disk answers instantly. For such cases there is a DriveTypeOverrides map in VDF's settings file, keyed by drive root, with value SSD or HDD:

"DriveTypeOverrides": {
  "D:\\": "HDD",
  "\\\\server\\share": "HDD",
  "/mnt/usb": "SSD"
}

An override always wins over automatic classification.

Native FFmpeg bindings

The native FFmpeg bindings (Settings > Processing) bring a large performance improvement because VDF calls the FFmpeg libraries directly instead of spawning an ffmpeg process per file. They require a recent shared, stable FFmpeg release; development/master builds are not supported and will crash. If native decoding fails for a file, VDF automatically falls back to the ffmpeg executable for it.

Hardware acceleration (GPU decode) can be enabled in the same section. auto picks a suitable method; none is the safe choice if decoding fails or thumbnails look corrupted.

General advice

• The first scan is always the slowest. Every file must be read and analyzed once; the results are cached in the database, so later scans only process new or changed files.
• Network storage: the network link, not the CPU, is the bottleneck. Network shares are automatically capped like hard disks, and for the heavy first scan of features that read whole files (audio fingerprinting, AI partial detection) it can be worth copying files to a local drive once; the extracted fingerprints stay in the database afterwards.
• Long scans are checkpointed: the database is saved automatically every few minutes during scanning (configurable under Settings > Database), so a crash or power loss does not lose hours of extraction work. Pausing or stopping a scan also saves progress.