[lkml]   [2003]   [Jun]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC] Breaking data compatibility with userspace bzlib
    On Fri, Jun 20, 2003 at 08:59:15PM +0200, J?rn Engel wrote:
    > Now, the cost of the underlying BWT is O(n) in memory and O(n*ln(n))
    > in time. That given, I consider it odd to use a linear semantic of
    > blockSizeXXXX and would prefer an exponential one, as the zlib uses
    > here and there. Thus blockSizeBits would now give the blockSize as
    > 1 << blockSizeBits, allowing to go well below 100k, resulting in lower
    > memory consumption for some and well above 900k, giving better
    > compression ratios.
    > Long intro, short question: Jay O Nay?

    The big question is whether the bzip2 better compression is actually
    useful in a kernel context? Patches to do bzip2 for initrd, for
    example, have been around for ages:

    But the compression and decompression overhead is _much_ larger
    than gzip. It was so huge for maximal compression that dialing back
    compression reaching a point of diminishing returns rather quickly,
    when compared to gzip memory usage and compression.

    I talked a bit with the bzip2 author a while ago about memory usage.
    He eventually added the capability to only require small blocks
    for decompression (64K IIRC?), but there was a significant loss in
    compression factor.

    So... even in 2003, I really don't know of many (any?) tasks which
    would benefit from bzip2, considering the additional memory and
    cpu overhead.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:36    [W:0.020 / U:21.308 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site