ECT trades a little size for a lot of time against zopfli

An optimizer that re-encodes the file, not just the archive

Efficient Compression Tool, or ECT, is described as a C++ file optimizer that supports PNG, JPEG, GZIP and ZIP files. The word optimizer rather than compressor is the useful part of that description, because it tells you the tool works inside the format rather than around it. For a PNG that means a different encoder and a different set of filter choices, for a JPEG a different quantisation and Huffman search, and for GZIP and ZIP a different deflate implementation. The target audience is whoever owns a pile of assets and wants them smaller without waiting an hour per file. The primary language recorded for the repository is C, with C++ in the description, and the tree shows a src directory, a doc directory, a licenses directory, a License.txt and a .gitmodules file, which is the visible sign that the compression codecs are vendored rather than written from scratch. The licences directory is also a reminder that a tool that bundles several upstream encoders carries their terms as well as its own, and the repository is published under Apache-2.0.

The level ladder reaches zopfli sizes without zopfli's clock

The README publishes a performance table for version 0.9.2, and it is the most useful thing in the documentation. The setup is stated precisely: all tests were run on macOS 12.5 using an Intel i7-7700HQ and clang, on the file enwik8 of 100,000,000 bytes compressed into gzip format. The result is that ECT at level 1 produced 36,493,257 bytes in 3.5 seconds, against gzip -9 at 36,475,811 bytes in 5.8 seconds, and against zopfli at iteration level 1 producing 35,102,371 bytes in 1 minute 30.2 seconds. From level 2 upward ECT closes the gap steadily, with 35,019,440 bytes in 14.8 seconds at level 2 against zopfli at iteration 5 taking 2 minutes 12.0 seconds for 34,983,757 bytes, and level 5 reaching 34,942,796 bytes in 25.1 seconds where zopfli at iteration 15 needs 3 minutes 59.9 seconds. The full ladder runs to level 9 at 34,937,781 bytes in 3 minutes 17.9 seconds, which is the closest ECT gets to zopfli at iteration 30. Read as a trade, the table says that on this input and this machine, a couple of minutes of extra CPU buys you roughly the size that zopfli needs six and a half minutes to reach. That is a good deal for a build step, and a bad deal for a request handler, which is the boundary worth remembering.

The clone has to be recursive, and nasm may be missing

The build instructions are short and one line of them is load bearing. To build ECT you need to recursively clone it, and just downloading is not enough, which the documentation spells out with the command:

git clone --recursive https://github.com/fhanau/Efficient-Compression-Tool.git

The .gitmodules file at the root of the tree is why. The compression backends are submodules, so a plain clone leaves you with a repository that builds nothing, and the failure mode is a confusing one because the top level looks complete. The second dependency is the assembler. The documentation notes you may also need to install nasm if it is not available already, and the reason becomes obvious in the Xcode section, where the assembly files inside mozjpeg have to be compiled by hand. This is the cost of the approach. ECT is not a single self contained binary you download and run, it is a build with a C toolchain, cmake, nasm and a set of vendored codecs that you compile yourself, which is a reasonable trade for a tool you run in CI or in a release pipeline and a poor one for a quick local experiment.

A three line cmake build, with one switch worth knowing

Once the sources are present the build is ordinary cmake, and the project keeps the classic out of source layout:

mkdir build
cd build
cmake ../src
make

There is one option the documentation calls out, and it is the kind of flag that saves a debugging session. Adding -DECT_MULTITHREADING=OFF turns off multithreading support. That matters for two different reasons. On a machine with few cores it removes a source of non deterministic behaviour, and in a container or a build sandbox where the core count is misreported it removes a class of hangs. The flag is mentioned as an option to turn various features on and off, so it is a reasonable place to look for others. The project also keeps a conventional script and project layout, with a .github directory for the workflow, a doc directory for documentation, a licenses directory collecting the terms of the vendored code, and the sources under src, which is where the cmake project lives. Nothing in the documentation suggests a packaged binary distribution, so the build is the entry point.

Xcode needs a custom rule for the mozjpeg assembly

The Xcode section is the longest part of the documentation and it is a good illustration of what vendored native codecs cost. To generate an Xcode project you add -G Xcode to the cmake command:

cmake ../src -G Xcode

The difficulty, as the documentation puts it, is that Xcode does not know how to compile some of the assembly files within mozjpeg. The fix is to locate the copy of nasm, open the Build Rules of the simd target and add a custom rule to process source files matching *.asm, with a script that invokes nasm with the mozjpeg include paths and produces a Mach-O object:

/usr/local/bin/nasm "-I${PROJECT_DIR}/mozjpeg" -DMACHO -D__x86_64__ "-I${PROJECT_DIR}/mozjpeg/simd/nasm/" "-I${PROJECT_DIR}/mozjpeg/simd/x86_64/" -f macho64 -o "${BUILT_PRODUCTS_DIR}/x86_64/${INPUT_FILE_BASE}.o" "${INPUT_FILE_PATH}"

There is an escape hatch for developers on macOS who do not need maximum speed, and it is the more interesting option. Adding -DWITH_SIMD=OFF to the cmake call disables the assembly files entirely, which removes the nasm requirement at the cost of the vectorised code paths. For most users, who are compressing a handful of files rather than benchmarking them, that is the sane default, and it is worth knowing that the flag exists before you spend an afternoon on Build Rules.

Apache-2.0, a 2024 release, and pushes that continued

The licence is Apache-2.0, recorded in License.txt at the root, with a licenses directory for the terms of the imported components. On maintenance, the picture is mixed and worth reading carefully. The tagged releases are ECT 0.9.3 on 2022-08-22, ECT 0.9.4 on 2023-01-23 and ECT 0.9.5 on 2024-01-08, so the last published version is more than two years old relative to the current date. The last push to the repository was on 2026-10-18, which means work has continued on the source without a new tag. Anyone who installs from a release therefore gets 0.9.5, and anyone who builds from master gets a later state of the tree that no published version corresponds to. For a tool whose selling point is a level ladder tuned over time, that distinction is worth making explicit rather than assuming. The documentation also does not say whether the published benchmark table has been rerun for the current source, and the table itself is labelled for version 0.9.2, so treat the numbers as a description of that release rather than a promise about the one you build.

Editorial conclusion

Adopt ECT if you have a batch of PNG, JPEG, GZIP or ZIP assets where the time spent compressing matters more than the last fraction of a percent, and you are comfortable with a build that pulls in submodules and an assembler. Do not adopt it as a replacement for a general purpose archiver with streaming or format coverage beyond the four listed types, and do not expect its published numbers to transfer to your own files, since the comparison in the README was measured on one machine with one input. Before you adopt, rebuild the levels you care about on your own assets, decide whether the assembler dependency is acceptable in your build environment, and check the release history, where the last tagged version is 0.9.5 from January 2024 while the last push was on 2026-10-18.

Frequently asked questions

Official sources

1. fhanau/Efficient-Compression-Tool on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases