Performance after you open the app.

Release build of the September 6 source (1fb20f0), measured using real files on an external SSD on an Apple M4 Max with 64 GiB RAM and macOS 26.6.2. Three-run medians after Metal initialization and one warm-up. Application startup and GUI redraw are excluded.

Creation includes reading the input files and writing the ZIP. Extraction includes reading compressed data from the ZIP and writing the extracted files. Both read and write real files on an external SSD.

Extraction also reuses ZIP inspection results in the resident process. Cleanup is outside the timer. Final archives passed 7-Zip validation and extracted content matched the source tree.

Measurement data (JSON) ↗

We also tested other applications with the same input data.

Creation time, extraction time, and ZIP size are shown side by side for standard ZIP and AES-256 across all seven public corpora. MetalArchiver and BetterZip are resident; Keka starts a fresh process for each operation.

Inputs, archives, and extraction destinations are real files on WorkDisk. Keka includes its CLI wrapper and bundled 7-Zip startup; BetterZip includes its official AppleScript API call through completion. Timing scopes differ, so no speedup ratio is calculated.

Standard ZIP

AES-256 ZIP

Keka uses ZIP / Deflate / -mx=5; BetterZip uses ZIP / Fast with Mac metadata excluded. Both use AES-256 when encrypted. Values are three-run medians. Archives and extracted contents were verified.

Measurement data (JSON) ↗

Every MetalArchiver cell uses September 6 measurements with startup excluded and file I/O included. Other columns retain the August 25 process-start-inclusive CLI measurements. Input sizes, file counts and content hashes match, but this is not a simultaneous comparison with matched startup and storage conditions.

Standard ZIP

Other tools extracted the MetalArchiver ZIP generated on August 25; current MetalArchiver extracts its newly generated ZIP. Source content is identical, but archive identity is not guaranteed. This is not a fresh all-product test of one identical ZIP.

AES-256 ZIP

WinZip AES-256 ZIPs of the same seven inputs. MetalArchiver uses the current measurements with startup excluded and file I/O included; minizip-ng + zlib-ng and 7-Zip retain the August 25 process-start-inclusive CLI records. These are reference comparisons with different timing scopes.

Extraction was not measured for minizip-ng + zlib-ng, so it is shown as “—”. large is an approximately 11.2 MB corpus; Artificial is diagnostic input. Metadata restoration settings are not fully aligned across products.

Measurement data (JSON) ↗

Measurement data (JSON) ↗

Timing scope and cache

Includes real-file reads, archive creation or extraction, and output writes. Process startup, Metal initialization, GUI redraw, cleanup and content verification are outside the timer. The OS file cache is enabled; this is not a cold-cache test that forces every byte to be read from the SSD on every run.

Tested versions

Keka 1.6.7, BetterZip 6.0.5, 7-Zip 26.02 (arm64), minizip-ng 4.2.2 + zlib-ng, and pigzpp d094a0e. The Info-ZIP version output retained in the record contains only a copyright line, not a complete version number.

Creation settings

Current MetalArchiver uses create defaults. Historical CLI settings: Info-ZIP and minizip-ng -6; 7-Zip and Keka ZIP / Deflate / -mx=5. Matching level numbers do not imply matching compression quality.

Environment

Current MetalArchiver: M4 Max / 64 GiB / macOS 26.6.2. Input, archive and extraction output used an external SSD with measured sequential read/write speeds topping out at approximately 2.6 GB/s. Historical CLI records use the same machine model, memory and OS. Because the OS file cache remains enabled, the displayed throughput represents the complete overlapping read, compression and write workload—not the SSD alone. The seven-corpus Keka and BetterZip tests also used WorkDisk. Storage conditions and SSD state are not necessarily equivalent across all measurements, including historical CLI records.

MetalArchiver revision

The seven-corpus MetalArchiver cells use 1fb20f0, measured September 6, 2026, with startup excluded and real-file reads and writes included. Process-start-inclusive CLI results and older MetalArchiver rows are not used in the displayed data. Large-data dates and conditions are listed in that section. These are not full GUI-operation timings.

Regression check

On September 5, we compared the pre-audit commit with the release-audit candidate on a RAMDisk. Across 28 combinations—seven corpora, ZIP and AES-256, creation and extraction—three-run medians after one warm-up showed no consistent performance regression.

Integrity

The records report 7-Zip integrity checks on final archives and byte-for-byte or source-tree fingerprint verification after extraction. Tables include archive size alongside creation time.

Reading the numbers

1 MiB is 1,048,576 bytes. Lower elapsed time is faster; higher MiB/s is faster. Throughput uses uncompressed/restored bytes. No speedup ratios or overall rankings are shown across the different timing scopes.

Inspect the measurement data

Current MetalArchiver JSON includes all three samples, revision, environment and input hashes. Original comparison JSON retains historical MetalArchiver rows for provenance, but those rows are not used in this page’s MetalArchiver cells. The large-data competitor test was run on September 5; peer values in the seven-corpus and CLI comparisons were not repeated for this update.