How does NTFS Compression impact performance on nvme SSDs in Windows 10 on 2021 hardware?

Question

I set up a File History backup nvme ssd in my laptop and wanted to share the results of a quick CrystalDiskMark benchmark with NTFS File and Folder Compression enabled and disabled. See answer below.

Answer 1

Hardware

This is a well-cooled laptop from 2021.

Processor       AMD Ryzen 7 4800HS with Radeon Graphics (2.90 GHz)
Installed RAM   16.0 GB (15.4 GB usable)
Tested SSD      Samsung SSD 970 EVO Plus 500GB
System type     64-bit operating system, x64-based processor
Edition         Windows 10 Home
Version         22H2
Installed on    ‎7/‎23/‎2021
OS build        19045.2965
Experience      Windows Feature Experience Pack 1000.19041.1000.0

Scenario 1: Compression OFF

1. Quick format as NTFS with default allocation size unit and NO compression.
2. Crystal Disk Mark: 1 pass, 32GiB, all scenarios.

------------------------------------------------------------------------------
CrystalDiskMark 8.0.4 x64 (C) 2007-2021 hiyohiyo
                                  Crystal Dew World: https://crystalmark.info/
------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

[Read]
  SEQ    1MiB (Q=  8, T= 1):  1789.330 MB/s [   1706.4 IOPS] <  4681.96 us>
  SEQ    1MiB (Q=  1, T= 1):  1520.689 MB/s [   1450.2 IOPS] <   688.45 us>
  RND    4KiB (Q= 32, T= 1):   515.591 MB/s [ 125876.7 IOPS] <   245.41 us>
  RND    4KiB (Q=  1, T= 1):    56.474 MB/s [  13787.6 IOPS] <    72.37 us>

[Write]
  SEQ    1MiB (Q=  8, T= 1):  1296.007 MB/s [   1236.0 IOPS] <  6456.03 us>
  SEQ    1MiB (Q=  1, T= 1):  1178.180 MB/s [   1123.6 IOPS] <   888.16 us>
  RND    4KiB (Q= 32, T= 1):   452.477 MB/s [ 110468.0 IOPS] <   280.43 us>
  RND    4KiB (Q=  1, T= 1):   183.973 MB/s [  44915.3 IOPS] <    22.12 us>

Profile: Default
   Test: 32 GiB (x1) [Z: 0% (0/466GiB)]
   Mode: [Admin]
   Time: Measure 5 sec / Interval 5 sec 
   Date: 2023/06/07 10:03:39
     OS: Windows 10  [10.0 Build 19045] (x64)

Scenario 2: Compression ON

1. Quick format as NTFS with default allocation size unit and compression turned ON.
2. Crystal Disk Mark: 1 pass, 32GiB, all scenarios.

------------------------------------------------------------------------------
CrystalDiskMark 8.0.4 x64 (C) 2007-2021 hiyohiyo
                                  Crystal Dew World: https://crystalmark.info/
------------------------------------------------------------------------------
* MB/s = 1,000,000 bytes/s [SATA/600 = 600,000,000 bytes/s]
* KB = 1000 bytes, KiB = 1024 bytes

[Read]
  SEQ    1MiB (Q=  8, T= 1):  1789.688 MB/s [   1706.8 IOPS] <  4681.73 us>
  SEQ    1MiB (Q=  1, T= 1):  1516.428 MB/s [   1446.2 IOPS] <   690.41 us>
  RND    4KiB (Q= 32, T= 1):   513.624 MB/s [ 125396.5 IOPS] <   247.03 us>
  RND    4KiB (Q=  1, T= 1):    51.837 MB/s [  12655.5 IOPS] <    78.85 us>

[Write]
  SEQ    1MiB (Q=  8, T= 1):  1772.207 MB/s [   1690.1 IOPS] <  4722.98 us>
  SEQ    1MiB (Q=  1, T= 1):  1513.156 MB/s [   1443.1 IOPS] <   691.69 us>
  RND    4KiB (Q= 32, T= 1):   450.992 MB/s [ 110105.5 IOPS] <   281.38 us>
  RND    4KiB (Q=  1, T= 1):   184.793 MB/s [  45115.5 IOPS] <    22.03 us>

Profile: Default
   Test: 32 GiB (x1) [Z: 0% (0/466GiB)]
   Mode: [Admin]
   Time: Measure 5 sec / Interval 5 sec 
   Date: 2023/06/07 9:59:37
     OS: Windows 10  [10.0 Build 19045] (x64)

Summary

This is a simple benchmark scenario that may not be indicative of real world File History access patterns, but I didn't want to set up something more complicated. I repeated each scenario once to confirm similar results.

• The sequential read and random write performance was unaffected.
• The random read, queue depth 1 performance decreased 8% with compression ON.
• The sequential write performance increased 28-38% with compression ON.

CPU utilization was collected using a custom Data Collector, monitoring % Processor Time and % of Maximum Frequency. My machine had lots of applications open during the test so the data was noisy. My observations are that a single core was fully utilized only twice for 10 seconds during the full test suite. Those 10 second periods did not correspond perfectly to particular phases of the test, but they were near the sequential write benchmarks. I assume it's somewhat related but the spikes may also be related to other operations on the PC. Besides that, per core CPU never spiked above 30% Processor Time (briefly), and was typically under 5% Processor Time. CPUs were running at full frequency for the duration of the test.

Conclusion

For my use case compression makes sense. I'll rarely access my backed up files, and random read performance doesn't suffer that much, so I'll take the benefit of faster sequential write performance and, more importantly, additional capacity. Compression didn't appear to stress my many-core CPU in a user-perceptible way, except possibly a single core during the sequential write benchmarks (timing is questionable).