Comments (7)
Actually it would probably be better to make a polyfill for CompressionStream
and DecompressionStream
backed by fflate
than to add support for it here. I can try to work on that in the coming days.
from fflate.
Actually it would probably be better to make a polyfill for
CompressionStream
andDecompressionStream
backed byfflate
than to add support for it here. I can try to work on that in the coming days.
this exposes a better API for files than those streams, so I think just accelerating the lib with them would be better but why not both?
from fflate.
Actually after profiling the performance, it actually tends to be faster just to use fflate
in most cases due to streaming overheads. However if anyone wants a Compression Streams API polyfill using fflate
, I've made one available at https://github.com/101arrowz/compression-streams-polyfill.
from fflate.
Just having a look at DecompressionStream
in Deno.
import { assert } from "https://deno.land/[email protected]/assert/mod.ts";
import * as fflate from "npm:fflate";
import * as pako from "npm:pako";
async function decode_stream(stream: ReadableStream) {
const reader = stream
.pipeThrough(new DecompressionStream("gzip"))
.getReader();
let bytes: Uint8Array;
{
const result = await reader.read();
assert(!result.done, "ReadableStream must have data");
bytes = result.value;
}
{
const result = await reader.read();
assert(result.done, "ReadableStream must have no more data");
}
return bytes;
}
const base = new URL(
"https://raw.githubusercontent.com/zarr-developers/zarr_implementations/5dc998ac72/examples/zarr.zr/gzip/.zarray",
);
const BYTES = await fetch(new URL("0.0.0", base))
.then((r) => r.arrayBuffer())
.then((b) => new Uint8Array(b));
const REFERENCE = fflate.gunzipSync(BYTES);
Deno.bench("decode_stream", async () => {
const stream = new ReadableStream({
start(controller) {
controller.enqueue(BYTES);
controller.close();
},
});
const result = await decode_stream(stream);
assert(result.length === REFERENCE.length);
});
Deno.bench("fflate.gunzip", () => {
const result = fflate.gunzipSync(BYTES);
assert(result.length === REFERENCE.length);
});
Deno.bench("pako.inflate", () => {
const result = pako.inflate(BYTES);
assert(result.length === REFERENCE.length);
});
> deno bench -A gzip.ts
cpu: Apple M3 Max
runtime: deno 1.39.1 (aarch64-apple-darwin)
file:///Users/manzt/demos/gzip.ts
benchmark time (avg) iter/s (min … max) p75 p99 p995
------------------------------------------------------------------- -----------------------------
decode_stream 40.66 µs/iter 24,591.2 (36.96 µs … 1.37 ms) 41 µs 62.92 µs 88.58 µs
fflate.gunzip 67.92 µs/iter 14,723.0 (63.83 µs … 1.68 ms) 66.62 µs 82.67 µs 88.25 µs
pako.inflate 112.22 µs/iter 8,910.9 (102.83 µs … 1.4 ms) 109.54 µs 139.58 µs 182.42 µs
summary
decode_stream
1.67x faster than fflate.gunzip
2.76x faster than pako.inflate
from fflate.
I don't think that's a fair comparison as you're wrapping fflate in a ReadableStream, realistically you wouldn't use readable streams for this
from fflate.
I’m not sure i understand. fflate is decompressing BYTES directly, there is no readable stream in an fflate code path. Only the non-fflate bench (decode_stream) creates the readable stream.
Might be worth looking into Deno.bench.
from fflate.
oh sorry, missread
from fflate.
Related Issues (20)
- Add Bzip2?
- Hangs on gunzipSync of compressed content with invalid dictionary HOT 3
- Option to shorten output as much as possible HOT 3
- Incorrect argument order in AsyncFlateStreamHandler HOT 5
- Truncated output of gunzip if SIZE footer is incorrect HOT 5
- return uncompressed size instead of resized output buffer HOT 4
- Improve zip documentation HOT 1
- The encoded data was not valid for encoding utf-8 HOT 1
- Streams onData do not work as expected anymore HOT 8
- CDN bundle for 0.8.1 is broken HOT 2
- Async unzip maxing out CPU and memory for some files HOT 3
- fflate.decompressSync is not a function when using `nifti-reader-js` (React) HOT 7
- Occasional CRC Errors When Streaming Data into Zip using AsyncZipDeflate HOT 7
- `zipSync` can get order of ZIP entries wrong, due to how objects work HOT 3
- delete the rust code
- The 2nd+ JPG images in a zip stream being created are corrupt for some reason? HOT 9
- `gunzipSync` failing (0 gzip length) on some npm package tarballs HOT 1
- Unexpected EOF when inflating ZIP HOT 3
- Unzip error thrown when big file as compression type 9 HOT 1
- Incorrect modules field for node.js HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from fflate.