I'll try to post a demo today. There's an interesting aspect to LZHAM's decoder, it's implemented with coroutines. My changes disable those, as they cause degenerate performance in a lot of cases, by creating massive switch statements.
If at least some of the coroutine yield points could be made to work without code bloat or speed impact, it would allow for streaming decompression which would go along way to reducing the overall impact of running the decompressor in Javascript. On Friday, September 18, 2015 at 10:44:00 AM UTC-7, Charles Vaughn wrote: > > I've got a little benchmark uncompressing 4MB of floats. On Chrome it's > 80ms, so 50MBps. > > On Wednesday, September 16, 2015 at 2:37:15 PM UTC-7, Alon Zakai wrote: >> >> I'm curious what decompression speeds you see for lzham? The compression >> ratios are impressive, but I assume that's at the cost of taking longer to >> unpack. >> >> On Tue, Sep 15, 2015 at 7:17 PM, Charles Vaughn <[email protected]> wrote: >> >>> If you're interested in checking out LZHAM, I've got that building for >>> emscripten here: https://github.com/hackcasual/lzham_codec >>> >>> For bananabread, I saw the following results for of the models: >>> >>> rw-rw-r-- 1 charles charles 385692 Sep 15 19:12 m134_hudguns.blend >>> -rw-rw-r-- 1 charles charles 138954 Sep 15 19:13 m134_hudguns.blend.lz4 >>> -rw-rw-r-- 1 charles charles 83108 Sep 15 19:14 >>> m134_hudguns.blend.lzham >>> >>> On Tuesday, September 8, 2015 at 5:11:26 PM UTC-7, Alon Zakai wrote: >>>> >>>> incoming now has optional LZ4 compression for file packages. What this >>>> lets you do is pre-compress your filesystem data, and keep it compressed >>>> in >>>> memory, and only decompress chunks on demand as they are read. This means >>>> that you can reduce the total amount of memory used by your application. >>>> >>>> LZ4 ( https://en.wikipedia.org/wiki/LZ4_%28compression_algorithm%29 ) >>>> is a very fast compression algorithm. In my benchmarks it makes little >>>> difference to I/O speed, and in general I/O from our in-memory filesystem >>>> is fast anyhow since it's already in memory. So the downside of needing to >>>> decompress seems small, I don't see much difference in BananaBread >>>> startup, >>>> for example, with or without LZ4 compression. >>>> >>>> Of course how useful this is depends on how compressible your data is. >>>> LZ4 can compress text very well, but often data in things like games is >>>> already compressed, like compressed textures and audio. Still, I saw >>>> 10%-25% compression on a few games I tried. >>>> >>>> Feedback and testing are very welcome. Some docs are at >>>> >>>> >>>> https://github.com/kripken/emscripten/blob/71bf8ed55ed03a96a018f76bf2003acf32db3235/src/settings.js#L250 >>>> >>>> but basically just run emcc with -s LZ4=1 . (If you run the file >>>> packager separately, you need to also pass --lz4 to it.) >>>> >>>> - Alon >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "emscripten-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
