miniz as an alternative to zlib in embedded platforms?

[adolfogc]

Hi,

Currently, zlib, if available, is used in development platforms (macOS, Linux). Would it make sense to use the miniz implementation in embedded platforms like ESP32?

• https://github.com/richgel999/miniz
• https://github.com/espressif/esp-idf/blob/v5.1.2/components/esp_rom/include/miniz.h

[fadushin]

Currently, zlib de/compression is only used in AtomVM when loading BEAM files, either by the (c-based) PackBEAM tool or in the (degenerate) case where a BEAM file is loaded on the command line on UNIX systems. zlib compression is currently not used (needed?) on ESP32 or other platforms, though I don’t know if platforms other than ESP32 benefit from mmap’ing decompressed literals, as ESP32 does.

That being said, the ERTS zlib interface may be worth implementing as a general API for all platforms, so this could definitely be useful, if/when someone decides to contribute such an API/implementation. Compression could also be useful internally, for example, in the ETS MVP (Issue #887).

[bettio]

I would like adding support for miniz when loading BEAM files on ESP32 (or maybe other platforms with miniz). If add miniz support (on platforms without a default zlib) for modules loading, we can use the REPL for copying&pasting new modules and loading them at runtime. I also agree about adding support to miniz/zlib for general data inflate / deflate.

[bettio]

This might be a useful snippet that I used on a different project, that might be a good starting point:

tinfl_decompressor decomp;
tinfl_init(&decomp);


tinfl_status decomp_status = tinfl_decompress(&decomp, source, &source_size, dest, dest, &uncompressed_size, TINFL_FLAG_PARSE_ZLIB_HEADER | TINFL_FLAG_USING_NON_WRAPPING_OUTPUT_BUF);
if (decomp_status != TINFL_STATUS_DONE) {
    return decomp_status;
}