Skip navigation

emCompress – Performance

emCompress can achieve best-possible compression ratios of 90% and above as well as decompression speeds of up to 5 MByte/sec on target side.

Performance depends on various factors

The compression ratio and decompression speed of emCompress are dependent on various factors and may vary in each case.

The main speed factors are:

  • The data to be compressed
  • The data size and redundancy
  • The compression codec
  • The decompression workspace size

ROM use

The amount of ROM that the embedded compression solution emCompress is using for decompression, varies with the codec selected. The table below measures the total ROM required for a single decoder, including all supporting functions and excluding integrity checks on the target device. 

STORE0.5 KByte
RLE-PAR0.8 KByte
HUFF1.3 KByte
LZW1.0 KByte
LZSS1.2 KByte
LZJU901.3 KByte

Some of the codecs share common code. Hence, if your compressed bitstreams only use DEFLATE, the amount of ROM required is easily read off from the table. If you are using more than one codec in your application, the amount of ROM is less than the sum of the used codecs.

Adding a table-driven CRC32 integrity check adds about 1.1 KB of code to the total emCompress ROM requirement. The following table lists the ROM requirements per codec.

RAM use

The amount of RAM that emCompress uses is under complete control as it is specified at compression time. Typically, 2KB of temporary RAM for decompression already yield good compression ratios, but even without temporary RAM, good compression ratios can be achieved in many cases. No static RAM is required, stack usage is well below 512 bytes.

Uncompressed Data (112 kByte ≙ 100%)
Properties emCompressed
Compression codec LZJU90 DEFLATE
Data size 30.5 kByte
23 kByte
Decompression RAM 2 kB 48 kB
Decompression speed* 3 MByte/sec 2 MByte/sec

* Running on Cortex-M4 @ 200 MHz

Decompressing and Processing Data

emCompress features two decompression functions.

The first one is decompression into memory. The complete data is decompressed and stored in a user-provided memory buffer. Although the buffer can be temporary, this requires to have enough free memory for the complete uncompressed data and the workspace. Decompression into memory can for example be useful for dynamic firmware images. The second function is decompression in streamed mode. emCompress will use a small temporary buffer whose size is set by the user when compressing. Once a fragment of data is decompressed and the buffer is filled, the user-provided output function is called and the next buffer filled again with the next fragment. Sreamed decompression is particularly effective for programming FPGAs or serving web content. To process our bitstream and send it to the FPGA, we do not have to do this in one go. So we can choose decompression in streamed mode and send the data fragment by fragment in the output function. We do not have to have free RAM for the complete decompressed bitstream (112 kByte) and can simply pass our output function FPGA_SendData() to the decompressor. To see how this is done and how easy emCompress is to use, look at the example application below. Decompression is not as fast as copying data or calling an output function directly, but for large data, which is processed once in a while, like a one-time setup of the FPGA while booting, the advantage of less space is more important than the time taken to decompress. The emCompress codecs are highly optimized to achieve fast speeds. Like the compression ratio, the decompression speed is dependent on various factors, like the data to be decompressed, the chosen codec and the temporary buffer size, and can vary. We decompressed our bitstream and calculated a checksum in the output function (without sending data to the FPGA) in 36 ms.