Zig: deflate implementation in standard library

Created on 9 Nov 2016  路  15Comments  路  Source: ziglang/zig

These compression and decompression functions are so common that we should have them ship with the compiler. We'll probably need to depend on them for the package manager.

contributor friendly enhancement standard library

Most helpful comment

OK, so we've had 3 decompressors so far, of which the earlier one appears to be a port of a C implementation, and the other two happen to both work on Zig 0.6.0.

As far as performance is concerned, it'll really only be slow if you aren't buffering your input. If you're using the InStream interface, then you can plug in a BufferedInStream and that'll magically fix the worst of it.

If this should be in the standard library, then what API should we provide? And what primitives would we want in the standard library to make this work?

I'm mostly thinking from the perspective of

Here's what I'm thinking in terms of an API:

pub fn DeflateInStream(comptime TypeInStream: type) type { ... }
pub fn GzipInStream(comptime TypeInStream: type) type { ... } // FIXME: What capitalisation should we use?
pub fn ZlibInStream(comptime TypeInStream: type) type { ... }

And as for primitives, we do have BufferedInStream, BitInStream, and hash.Crc32 already (daurnimator pointed some of these out on IRC), but we're likely to need something like these to become a thing (names and interfaces TBD):

pub fn CanonicalHuffmanReader(... TODO ..., comptime out_type: type, max_len: usize) type { ... }
pub fn LzSlidingWindow(... TODO ..., comptime size: usize) type { ... }

Thoughts?

All 15 comments

Commenting here since Github won't let me be assigned.

I'll try to look into this asap

@itsmontoya @schmee did either of you get anywhere on this issue?

I didn't write it, but I found this: https://github.com/tiehuis/zig-deflate that looks pretty far along

the implementation that is based on isn't designed for speed.

@daurnimator I'm messing around with it but no promises about when/if I'll be done. So if someone else wants to work on this please feel free! 馃檪

Once this is done it should be used so that we can store the glibc data compressed (see https://github.com/ziglang/zig/pull/2847#issuecomment-509276642 )

This is a really nice article on the subject: https://www.hanshq.net/zip.html

I'll writing one for PNG support in zigimg

Currently working on an implementation myself. I've got decompression working (it's about 1/4 of the speed of gunzip although it doesn't write to an actual output file yet), and I started working on a compressor yesterday, although that hasn't been pushed yet.

https://github.com/iamgreaser/deflate-for-zig/

I can be found on #zig under the name GreaseMonkey, if you have any suggestions then let me know.

My current progress is here: https://github.com/mlarouche/zigimg/blob/ReadPNGSupport/src/compression/deflate.zig Haven't mesured performance yet

OK, so we've had 3 decompressors so far, of which the earlier one appears to be a port of a C implementation, and the other two happen to both work on Zig 0.6.0.

As far as performance is concerned, it'll really only be slow if you aren't buffering your input. If you're using the InStream interface, then you can plug in a BufferedInStream and that'll magically fix the worst of it.

If this should be in the standard library, then what API should we provide? And what primitives would we want in the standard library to make this work?

I'm mostly thinking from the perspective of

Here's what I'm thinking in terms of an API:

pub fn DeflateInStream(comptime TypeInStream: type) type { ... }
pub fn GzipInStream(comptime TypeInStream: type) type { ... } // FIXME: What capitalisation should we use?
pub fn ZlibInStream(comptime TypeInStream: type) type { ... }

And as for primitives, we do have BufferedInStream, BitInStream, and hash.Crc32 already (daurnimator pointed some of these out on IRC), but we're likely to need something like these to become a thing (names and interfaces TBD):

pub fn CanonicalHuffmanReader(... TODO ..., comptime out_type: type, max_len: usize) type { ... }
pub fn LzSlidingWindow(... TODO ..., comptime size: usize) type { ... }

Thoughts?

Looks good to me :)

@andrewrk please reopen since DEFLATE is not yet implemented

std.compress.deflate.inflateStream

ahh I see, my mistake.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

andrewrk picture andrewrk  路  3Comments

bronze1man picture bronze1man  路  3Comments

andrewrk picture andrewrk  路  3Comments

andrewrk picture andrewrk  路  3Comments

komuw picture komuw  路  3Comments