You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thanks for creating this project. I did read the line (below) from the README.md, and feel free to close this issue if this is not in the scope.
This library is a JavaScript binding to zopfli with WebAssembly. This is slower than native extensions for zopfli, but because wasm is a portable binary format, its installation is much easier than native extensions.
I was using node-zopfli to gzip the files in our dist folder. Due to the hassle of using node-gyp, I decided to switch to this package. I noticed though that for our artifacts, it took roughly 4 times longer to gzip all the files (~6s to ~22s).
1 The gtag script was copied until it reached the target size 2 The gtag script was copied into 8 files with sizes varying from 100KB to 1MB 3 Our project has 4 javascript files with their respective .map files, with sizes between 100KB and 1MB
Scripts
Below is the script used to transform files (executed with node --experimental-modules <file>). I also tried using @gfx/zopfli with a stream transform (inpsired by node-zopfli), but it did not seem to affect the speed (I had a theory that streams due to backpressure could be more effective).
node-zopfli
importfsfrom'fs';importglobfrom'glob';importzopflifrom'node-zopfli';import{join}from'path';import{promisify}from'util';import{pipeline}from'stream';main().then(()=>console.log('Files have been successfully gzipped.')).catch(err=>console.error(err));asyncfunctionmain(){constdistFolder=join(process.cwd(),'dist');constgzipFolder=join(distFolder,'gzip');try{awaitfs.promises.mkdir(gzipFolder,{recursive: true});}catch(err){if(err.code!=='EEXIST')throwerr;}constpipe=promisify(pipeline);constfiles=awaitpromisify(glob)('*!(.d.ts)',{nodir: true,cwd: distFolder});awaitPromise.all(files.map(p=>pipe(fs.createReadStream(join(distFolder,p)),zopfli.createGzip(),fs.createWriteStream(join(gzipFolder,p)))));}
@gfx/zopfli
importfsfrom'fs';importglobfrom'glob';importzopflifrom'@gfx/zopfli';import{join}from'path';import{promisify}from'util';main().then(()=>console.log('Files have been successfully gzipped.')).catch(err=>console.log(err));asyncfunctionmain(){constdistFolder=join(process.cwd(),'dist');constgzipFolder=join(distFolder,'gzip');try{awaitfs.promises.mkdir(gzipFolder,{recursive: true});}catch(err){if(err.code!=='EEXIST')throwerr;}constfiles=awaitpromisify(glob)('*!(.d.ts)',{nodir: true,cwd: distFolder});awaitPromise.all(files.map(asyncp=>{constbuffer=awaitfs.promises.readFile(join(distFolder,p));constgzipped=awaitzopfli.gzipAsync(buffer,{});awaitfs.promises.writeFile(join(gzipFolder,p),gzipped);}));}
@gfx/zopfli (transform stream)
importfsfrom'fs';importglobfrom'glob';importzopflifrom'@gfx/zopfli';import{join}from'path';import{promisify}from'util';import{Transform,pipeline}from'stream';main().then(()=>console.log('Files have been successfully gzipped.')).catch(err=>console.error(err));asyncfunctionmain(){constdistFolder=join(process.cwd(),'dist');constgzipFolder=join(distFolder,'gzip');try{awaitfs.promises.mkdir(gzipFolder,{recursive: true});}catch(err){if(err.code!=='EEXIST')throwerr;}constpipe=promisify(pipeline);constfiles=awaitpromisify(glob)('*!(.d.ts)',{nodir: true,cwd: distFolder});awaitPromise.all(files.map(p=>pipe(fs.createReadStream(join(distFolder,p)),newGzip(),fs.createWriteStream(join(gzipFolder,p)))));}classGzipextendsTransform{constructor(){super();this.in=newBuffer.alloc(0);}_transform(chunk,encoding,done){this.in=Buffer.concat([this.in,chunk]);done();}_flush(done){zopfli.gzip(this.in,{},(err,out)=>{if(err){done(err);}else{this.push(out);done();}});}}
Is .wasm the reason for the slowdown?
Is it within reason that @gfx/zopfli is sometimes ~4x slower than using node-zopfli?
Or maybe I've done something weird in the script?
@gfx/zopfli version: 1.0.13
Edit: Added version info
The text was updated successfully, but these errors were encountered:
Thanks to the report. This library may be much slower than node-zopfli, but I have not investigated it deeply. It could be wasm / emscripten issues; maybe it's time to investigate the performance.
BTW I use this library in production, and because node-zopfli is sometimes failed to build and I don't want to relay on node-gyp, I have no choice except for @gfx/zopfli.
Great library! I'm so looking forward to using this in my projects.
With relation to Emscripten's runtime performance: from my limited experience, the usual suspect for a bottleneck in V8 is cross-boundary calls (JS to WASM, or WASM to JS), including memory management, copying return values, things like that.
@gfx I agree, I just upgraded to Node v12, and node-pre-gyp was missing pre-builts for that version, and I spent way too long to try to make node-gyp build without errors (without succeeding). I was just hoping for having the best of both worlds (no node-gyp and around the same performance) 😉
Hello!
Thanks for creating this project. I did read the line (below) from the
README.md
, and feel free to close this issue if this is not in the scope.I was using
node-zopfli
to gzip the files in ourdist
folder. Due to the hassle of usingnode-gyp
, I decided to switch to this package. I noticed though that for our artifacts, it took roughly 4 times longer to gzip all the files (~6s to ~22s).1 The gtag script was copied until it reached the target size
2 The gtag script was copied into 8 files with sizes varying from 100KB to 1MB
3 Our project has 4 javascript files with their respective
.map
files, with sizes between 100KB and 1MBScripts
Below is the script used to transform files (executed with
node --experimental-modules <file>
). I also tried using@gfx/zopfli
with a stream transform (inpsired by node-zopfli), but it did not seem to affect the speed (I had a theory that streams due to backpressure could be more effective).node-zopfli
@gfx/zopfli
@gfx/zopfli (transform stream)
Is
.wasm
the reason for the slowdown?Is it within reason that
@gfx/zopfli
is sometimes ~4x slower than usingnode-zopfli
?Or maybe I've done something weird in the script?
@gfx/zopfli version: 1.0.13
Edit: Added version info
The text was updated successfully, but these errors were encountered: