3 ms·
It looks like that compresses/decompresses the data in one blocking step, unless I'm missing something. It doesn't handle if (say) the last bit of input ends in
by silentbicycle 14y ago
It looks like that compresses/decompresses the data in one blocking step, unless I'm missing something. It doesn't handle if (say) the last bit of input ends in the middle of a byte. Does it pad up every compression step output, or do it just assume the whole data set will be resident in memory at once?
heatshrink can suspend and resume, working in small increments. That's particularly important in embedded and hard real-time systems -- they typically can't block for long. Microcontrollers rarely have enough memory to store all the compressed and decompressed data at once.
Most of the work went into co-routining LZSS in little memory, not LZSS itself. LZSS is pretty simple.
I did run across that while doing research for my embedded project and forgot to mention it. (It was one I skipped due to blocking for too long. It's a good implementation otherwise.) I added it to the article.
- m_eiman 14y agoYes, it does its work in one go so it doesn't play well with hard realtime and variable sized/large work units (unless you've got an OS that handles task swapping as needed, of course). We selected it for our embedded devices based on its small code size and suitable license, and since we use it mostly to compress log data with lots of repetitions it works very well.
- silentbicycle 14y agoIf you've got an RTOS with pre-emptive threading, you can do blocking (de)compression safely...but then you need extra memory for another thread stack. It's a good implementation if that isn't an issue, but then there's a couple tiny LZSS/LZW/etc. implementations available.