The version 3.0.0 is not async in chrome

[CVex2150J]

I was using jszip 2.6.0 for at least 1 years and it work great with a minus problem("stopping" javascript execution for a while) but it was "ok". Now with the chrome upgrade 50.0.2661.75 m I get "aw snap" page most of the time (I zip a large string therefore stalling the javascript for more than 20 sec of work).
I'm really happy to see v3.0.0 with all thoses async methods. But during my tests for the last 2 days to solve my "aw snap" problem I found that on chrome 50 and using the latest build and async functions... my javascript block at generateAsync()

I did a test on NodeJS and it seems to work ok (not 100% sure)

There is a screenShot of chrome devTool. I tried to generate a zip with 22 files in it (~21MB of data). The flush function block all javascript execution for 4.73s.

I will use multiple zips generation as a work around for the moment.

[dduponchel]

Could you give us a code sample ? Several things can affect the speed: the type of file contents, parameters given to file(name, data), generateAsync(), etc. But not to that point.
In your case, I can see several _tickAndRepeat that should be separated by at least some milliseconds.
I tried to reproduce the issue (with Chromium 50.0.2661.75 and 20 files of 1 MB) but I get ~100ms chunks of executions separated by ~10ms. Here is the code I used.

[CVex2150J]

I tried your script with multiple 1MB files and it`s worked. I tested mine with File or ArrayBuffer, and it worked too. However, when I used a bigger file 10 - 20MB for example, I got the same behaviour as my first post.
Is there a kind of task splitting when one file is to heavy to be done in one go?
I will do more testing during the week-end.

[dduponchel]

It looks like the issue comes from asap which isn't the right tool here. The documentation says

ASAP strives to schedule events to occur before yielding for IO, reflow, or redrawing.
[...]
If this is a problem, you may be able to use ASAP’s cousin setImmediate to break long processes into shorter intervals and periodically allow the browser to breathe.

YuzuJS/setImmediate updates the global object, I'll check zloirock/core-js.

[CVex2150J]

I just tried the pull request and nothing change in the chrome profile. There is always a big long flush() call if the file is large enough. I tested it in nodejs ( simple fs readFile -> zipping uInt buffer and trying to write a stdout every sec) and it freezed for couple of second every time. I'll post script and zip sample to be able to test the code from now on.

[dduponchel]

@CVex2150J I updated the plunker here to use https://rawgit.com/dduponchel/jszip/fix_280_dist/dist/jszip.js instead of the v3.0.0 file and I get the expected result (I get the bug with the old plunker, not with the new one):

Same with nodejs. With the following script

var JSZip = require("./jszip_pr288");
var fs = require("fs");
var tickCount = 0;
setInterval(function () {
    console.log("tick", tickCount);
    tickCount++;
}, 200);

var zip = new JSZip();
for (var i = 1; i <= 20; i++) {
    // 20 files, generated with
    // for i in `seq 1 20`; do
    //   dd if=/dev/urandom of=$i.data bs=1M count=$i
    // done
    zip.file("" + i, fs.readFileSync(i + ".data"));
}

console.log("start");
zip.generateAsync({type:"arraybuffer", compression:"DEFLATE"})
.then(buffer => console.log(buffer));

I get regular tick in the console.

How do you reproduce your issue with the updated files from the pull request ?