Your Mac is slowing you down (a rant about file systems)

Overview

The video is a technical rant/benchmark deep-dive into why a MacBook using APFS feels dramatically slower for “agentic dev work”—tasks like:

• cloning repositories
• creating many work trees
• running pnpm install
• cleaning/removing node_modules-style directories

The speaker’s core argument: the bottleneck is file-system behavior, not raw CPU or SSD speed.

---

Core performance findings (macOS vs Linux)

Folder deletion / cleanup

• macOS: folder deletion during project cleanup took about ~35 seconds
• Linux: the same operation took under ~7–12 seconds

pnpm install benchmark

• Linux: finished install + post-install steps in <10 seconds
• macOS: was still mid-install when the video moved on (implying much slower performance)

Not just “faster drive” performance

The speaker emphasizes this is not purely a storage speed issue. Even if the Mac SSD is faster, the file-system layer is the main differentiator.

---

Sponsorship: CodeRabbit (unrelated to file systems)

The video includes a sponsored segment about CodeRabbit “Change Stack” UI for pull requests, featuring:

• PR overview with “blockers”
• a timeline view showing changes over time
• an “agent” button to chat/ask questions about the PR
• grouping files into “logical stacks” instead of alphabetical ordering

The framing is that it helps humans review large PRs more effectively.

---

Why file systems matter for agentic workflows

The speaker provides conceptual background:

• SSDs store blocks of bytes
• the OS provides an “illusion” of files and folders via metadata
• performance depends heavily on how the file system handles operations like:
  • delete
  • copy/move
  • links / dedup
  • small files and metadata operations
  • copy-on-write (CoW) and related mechanisms

Agentic workloads are especially sensitive because they often involve:

• cloning large repos
• copying many small files
• frequent work tree creation
• repeated install/cleanup cycles

---

Candidate file systems discussed

macOS: APFS

• Historically praised for successful migration from older Apple file systems
• But argued to be poor for the agent/worktree workflow
• Especially problematic when operations involve large numbers of metadata-heavy changes (e.g., hard-link patterns)

Linux options

• ext4
  • relatively simple/minimal
  • generally fast, but with fewer advanced features (limited advanced CoW/linking behavior)
• XFS
  • extensible and able to be paired with additional layers
• ZFS / btrfs
  • often better known for advanced storage features
  • but shown as less ideal for this specific workload (worse cleanup/creation times depending on mode)
• btrfs
  • mentioned as promising
  • but tests reportedly showed rough small-file copy behavior

---

Key “recommended” approach: XFS + VDO + LZ4

A friend (Wendell from Level1Techs) suggested:

• XFS + VDO + LZ4

The idea:

• insert a compression/dedupe layer (VDO) between XFS and the physical drive
• use LZ4 as lightweight compression to reduce space with limited performance penalty
• target lower write amplification and improved cloning/copy behavior by compressing/repacking at the block layer

---

Benchmark details (work trees, installs, and space)

Workflow benchmark setup

The speaker describes a repo benchmark setup including:

• a monorepo
• git clean cleanup
• pnpm install

Speed comparisons

• APFS: described as “garbage” repeatedly in the workflow context (slower install/cleanup numbers)
• ext4 vs XFS:
  • XFS positioned as notably faster than APFS for cleanup/install
• ZFS and btrfs:
  • shown as not ideal for this agent-worktree pattern (performance varies, but cleanup/creation times are generally worse)

Space usage results

Speed isn’t the only axis—space usage differs dramatically:

• ext4: reportedly uses much more space in this scenario (less effective linking/CoW/compression)
• XFS + VDO: reportedly reduces storage dramatically, with the speaker citing multi-x savings in some scenarios

Practical theme:

Ideally, creating a new work tree should not duplicate the entire repo on disk when only a small subset changes. File-system-level dedupe/linking/compression can prevent “absurdly massive” space waste.

---

Hard links as a major factor

Hard links strongly influence the results, especially with package manager workflows (notably PNPM):

• moving to hard links can flatten performance gaps between file systems
• tradeoff:
  • some file systems make hard-link creation expensive
  • the speaker notes APFS can become extremely slow when creating lots of hard links

---

Real-world impact shown

The speaker demonstrates agent-style work:

• Linux (with the chosen file system setup):
  • cloning + install workflow becomes “basically instantaneous”
• macOS:
  • the same workflow shows visible long cloning/waiting, described as “bad”

---

Final recommendations / conclusions

• The speaker concludes that moving agent workloads to a Linux machine helps significantly.
• A further improvement came from using XFS with VDO compression (LZ4) on a separate data partition:
  • faster work tree + install + cleanup
  • much more storage-efficient
• They say they wouldn’t necessarily require a brand-new file system, but current macOS options don’t match the needs of this agentic workflow.

---

“Rift” by Anomaly (optional alternative)

The speaker also mentions Rift (Anomaly) as a potential workaround for Mac work-trees:

• virtualizes files for the agent
• uses copy-on-write behavior so changes aren’t persisted until written
• described as instantaneous on macOS

Notes included:

• claimed Mac support, with some Linux compatibility mentioned (works with btrfs referenced)
• potential concern: the project may be stalled (last commit ~2 months ago per the speaker)

---

Main speakers / sources

• Main speaker: the YouTube creator/narrator focused on file systems and benchmarking
• External reference: Wendell (Level1Techs) — suggested XFS + VDO + LZ4
• Benchmark referenced: Novox — “Novox’s bench” for git/pnpm clean and install performance testing
• Sponsor/product mentioned: CodeRabbit
• Product mentioned: Rift by Anomaly