User: Password:
|
|
Subscribe / Log in / New account

Squashfs submitted for the mainline

Squashfs submitted for the mainline

Posted Oct 30, 2008 11:59 UTC (Thu) by epa (subscriber, #39769)
In reply to: Squashfs submitted for the mainline by Tuxie
Parent article: Squashfs submitted for the mainline

But can you guarantee a maximum memory usage for decompressing? With gzip you can allocate a 32kbyte window and a little bit of housekeeping and you're guaranteed to decompress any valid stream. No dynamic memory allocation is needed. Can LZMA say the same?


(Log in to post comments)

Squashfs submitted for the mainline

Posted Oct 30, 2008 13:22 UTC (Thu) by ajb (subscriber, #9694) [Link]

If you're doing the compressing, you ought to be able to guarantee a memory limit for decompression. Just try decompressing while you still have the original around, and tweak the compression parameters if you run out of memory. That's how MPEG encoders work - consumer products that do mpeg stream decompression have a defined amount of memory (2Mbits, if I remember correctly).

Admittedly that might be considered an expensive solution, but it proves that a solution exists.

Squashfs submitted for the mainline

Posted Oct 30, 2008 13:42 UTC (Thu) by Tuxie (guest, #47191) [Link]

According to Wikipedia, "LZMA is effectively deflate (zlib, gzip, zip) with a larger dictionary size, 32MB instead of 32kB".

It also say: "the amount of RAM required during decompression is principally determined by the size of the sliding window used during compression. Small code size and relatively low memory overhead, particularly with smaller dictionary lengths, make the LZMA decompression algorithm well-suited to embedded applications."

I'm not sure if that's a good enough answer. :)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds