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
Just found this tonight and, wow, it does exactly what it says! Seems pretty magical, frankly.
The only thing that tempered my sense of awe was seeing the browser process hosting this webapp shoot up to almost 2GB of RAM in task manager while preparing a 42MB ZIP file of images. Chrome itself became unresponsive for a couple minutes while Windows frantically paged memory to disk to let the app finish its work. (I have an embarrassingly small amount of RAM for 2017.)
This happened twice, with two different albums (one 42MB, one 29MB).
Given Stuk/jszip#135, I'd wager that the RAM use is coming from the ZIP file creation itself. I realize this app is probably using a different library, but JavaScript-based ZIP is still JavaScript-based ZIP, and is likely to still face similar issues.
Probably-important info about my environment:
Chrome 60.0.3112.101 (64-bit)
Windows 7 x64
4GB physical memory (the reason I usually have task manager open: to see what's hogging RAM)
The text was updated successfully, but these errors were encountered:
Oof. That really is a lot of ram. That is the js library I'm using, but since i built this 4 years ago it's using v1. I could maybe upgrade that library if newer versions have better memory performance.
Just found this tonight and, wow, it does exactly what it says! Seems pretty magical, frankly.
The only thing that tempered my sense of awe was seeing the browser process hosting this webapp shoot up to almost 2GB of RAM in task manager while preparing a 42MB ZIP file of images. Chrome itself became unresponsive for a couple minutes while Windows frantically paged memory to disk to let the app finish its work. (I have an embarrassingly small amount of RAM for 2017.)
This happened twice, with two different albums (one 42MB, one 29MB).
Given Stuk/jszip#135, I'd wager that the RAM use is coming from the ZIP file creation itself. I realize this app is probably using a different library, but JavaScript-based ZIP is still JavaScript-based ZIP, and is likely to still face similar issues.
Probably-important info about my environment:
The text was updated successfully, but these errors were encountered: