Worker improvement

1.  Use a single web worker for all deflating/inflating tasks in a ZipReader/ZipWriter, instead of one worker for one entry. This significantly reduces the overhead of creating web workers when processing zip file with many entries. However, users now must call `close()` when they done with ZipReader/ZipWriter, or the worker is leaked.

2.  Separate codecs (Inflater/Deflater) and worker codes, and allow pluggable DEFLATE implementations. Now zip.js can work with zlib-asm and pako.

3. Avoid copy ArrayBuffer's between workers and main thread.

4. Move crc32 into worker, further reduce main thread's load.

Static analysis tools such as jshint can easily detect unused and
undeclared variables, so ease of refactoring speaks in favor of not using a
prototype member, because the latter cannot be statistically analysed due
to the dynamic nature of JS.

Prototype members are comparable to instance members in class-based
languages, and you would probably agree that such constants should be
declared as a static constant member, e.g Crc32.table or CRC32_TABLE.
On Nov 5, 2014 12:31 PM, "Duan Yao" <notifications@github.com> wrote:

> In WebContent/z-worker.js:
>
> > +	Crc32.prototype.get = function get() {
> > +		return ~this.crc;
> > +	};
> > +	Crc32.prototype.table = (function() {
> > +		var i, j, t, table = []; // Uint32Array is actually slower than []
> > +		for (i = 0; i < 256; i++) {
> > +			t = i;
> > +			for (j = 0; j < 8; j++)
> > +				if (t & 1)
> > +					t = (t >>> 1) ^ 0xEDB88320;
> > +				else
> > +					t = t >>> 1;
> > +			table[i] = t;
> > +		}
> > +		return table;
> > +	})();
>
> I think Crc32.prototype.table is obviously shared because it is on the
> "prototype". The correct way to hack the table should be var crc = new
> Crc32(); crc.table = myCrcTable;.
>
> Modifying a member's internal data, i.e. obj.foo.bar = yyy always has the
> problem you mentioned, if you are not sure foo is shared or not. This is
> not specific to a prototype.
>
> I agree "class" and prototype in JS are the hard parts and not everyone
> understands them well, but they are worthy to learn.
>
> CRC32_TABLE has a small issue: it is not obviously belong to Crc32
> exclusively. If we want to move Crc32's code to another place, is it safe
> to move CRC32_TABLE also? We need to find out all codes using it.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/gildas-lormeau/zip.js/pull/108/files#r19867493>.
>