-
Notifications
You must be signed in to change notification settings - Fork 180
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zero-copy rom source data possible ? #35
Comments
It could be adapted to use ROM for the input buffer, but it might be a fairly deep change. The buffering impacts the algorithm - it needs to have a full buffer to do (de)compression, because it needs to have a fixed amount of the recent context. It'd be worth a try - adding a variant of sink() to the API that updates a pointer to a const uint8_t region would probably be the way to go. |
The API would probably look like:
and essentially the same for the decoder. A #define could compile out either the sink/poll API or the set/step input API. |
Fwiw, I just grabbed the low hanging fruit: duplicate the sink() function, and modify it to read directly from Flash. It elimates a memcpy() for each buffer fill with minimal changes to heatshrink. https://github.com/sutaburosu/scintillating_heatshrink/blob/master/heatshrink_decoder.ino#L140-L159 Thanks for an awesome library, Scott. It has helped me to achieve things on AVR that I didn't think I would be able to do without a bigger platform. |
Great! Duplicating |
Another developer and I have been discussing this, reworking the IO model to accommodate zero-copy will be a more substantial change, we are planning it as one of the major features for 0.5. |
A use case for heatshrink is storing data in flash compressed and decompressing it to a RAM buffer as needed (the original blog post seems to show the library came from this very need). However, the current design implies copying data to RAM input buffer. this is necessary if the data is in a file, but not if it's in ROM/ MCU flash : in this case the data is readily available to use, however the implementation stores the input buffer right next to decompression window buffer.
Would it be possible to provide separate source data as a pointer to ROM + decompression scratch data - avoiding sink interruptions, unnecessary copies and RAM consumption or is copying and proximity of those buffers necessary by the algorithm ?
Thanks, makapuf
The text was updated successfully, but these errors were encountered: