diglloydTools Updated to v 2.2.15, IntegrityChecker Sees up to 38% Speed Improvement
Need help deciding on a Mac? Lloyd offers one-on-one consulting on choosing the best Mac and its best configuration, backup protocol, displays, storage and RAID, etc.
Get diglloydTools and please consider subscribing to my photographic publications also.
Update: icj (Java version of IntegrityChecker is now up to 50% faster on very fast SSDs).
diglloydTools works fine with macOS High Sierra—no known issues, and no update was needed.
This is a minor update unless it matters to you in which case it is a nice bump up in speed; see the release notes. Current diglloydTools customers can download the update.
There is a cross-platform Java-based version of IntegrityChecker included (works on Windows, Linux, NAS OS, any operating system with Java). The existing native IntegrityChecker remains; the Java-based version is included in addition.
The only significant changes is that diglloydTools IntegrityChecker is now up to 38% faster on drives that offer at least 1.6 GB / sec transfer speed. Full performance gains in IntegrityChecker require at least 2.4 GB/sec which is darn fast, but the 2017 iMac 5K with its 3 GB/sec SSD benefits, as well as the 2016/2017 MacBook Pro models. Or any machine with fast enough disk I/O to keep the CPU cores busy. An 8-core machine will need something like 4.5 GB/sec, since IntegrityChecker is as efficient as it gets for disk I/O and CPU core usage on the Mac. This all relates to yesterday’s CPU core discussion.
There was no actual processing code optimization; IntegrityChecker has been capable of the same speed for years via the --num-threads option at the command line. What has changed is that more threads are now used by default, one for each virtual CPU core instead of one for each real CPU core. There was not much point in doing this prior to the advent of SSDs capable of speeds approaching 3GB/sec.
Examples: speed on the 2017 iMac 5K
Shown below, the 2017 iMac 5K with its 3 GB/sec SSD offers enough I/O bandwidth to keep IntegrityChecker busy with 8 threads, going at 2282 MiB/sec = 2390 MB/sec. The limitation here is CPU cores (4 real, 8 virtual). IntegrityChecker could use more CPU power. Also, other background applications consume some of the available CPU cycles.

Below, a relatively slow hard-drive based RAID-0 stripe can only be read at about 677 MiB/sec = 710 MB/sec. There are plenty of CPU cycles left over going unused—4 CPU cores are ample for this scenario.

Some of the other capabilities in diglloydTools
Aside from testing hard drive or SSD or RAID performance and reliability with DiskTester, data integrity with IntegrityChecker is a must-have workflow tool for anyone with important data:
- Checking drives before putting into “production”
- What a Bad Hard Drive Fails Like when Running diglloydTools 'fill-volume'
- diglloydTools IntegrityChecker Java Version: Finds Duplicates, Saved me 100GB!
- Reader Question: diglloydTools IntegrityChecker to address “had an experience where a number of my RAW files were silently corrupted”
- Detecting Corruption / Validating Data Integrity Over Time and Across Drives and Backup/Restore
- What an Impaired SSD Looks Like
- How to Safely Transfer Data or Verify Backups
- Example of Verifying Data Integrity.
- Are Your Backup Drives Still Functional? Are Your Files Subtly Damaged?
- How to Automate DiskUtility Verification of Mounted Volumes.
- Selling that Computer? Wipe Out Personal Files First
- Search for diglloydTools articles.