Fix "No memory" error and freezing a browser tab

[AnastasiaSliusar]

This PR has solutions for #43 and #45
Freezing a browser tab happened when decompressed data could be large. For example, when compressed file has 10MB, but decompressed data has 98MB.

Since real decompressed data size is not known, as the solution is to take a average compressed ratio according to the example of compressed file of 10 MB and realize inital memory for (size of compressed file * compressed ratio)MB. Drawback is that the more decompressed data is the slower archive_read_data method is itself.

[martenrichter]

Maybe some ideas for handling larger archives, I had these already two weeks before, but they were not necessary.
Instead of a single wasm function, that decompresses the whole archive, you can divide the function into three parts:
(i) Initializing the libarchive for the archive and setting up other datastructures (basically the part before for the loop through the archive).
(ii) A function that processes a single file, or a bunch of files (may be limited by a number or maximum number of occupied memory). This function can then be called in a loop from javascript, copying over the results to the destination.
Maybe you can recycle some of the memory for the files in the next turn.
(iii) A cleanup function., that closes all objects allocated and opened in (i) and maybe in (ii)

Of course, you could put it into a ReadableStream, as this is how webstreams work.
The benefit would be that you can potentially decrease the memory of the Wasm build, allocate a smaller size of intermediate memory buffers, and overall, run the whole setup in less powerful devices.

[AnastasiaSliusar]

Maybe some ideas for handling larger archives, I had these already two weeks before, but they were not necessary. Instead of a single wasm function, that decompresses the whole archive, you can divide the function into three parts: (i) Initializing the libarchive for the archive and setting up other datastructures (basically the part before for the loop through the archive). (ii) A function that processes a single file, or a bunch of files (may be limited by a number or maximum number of occupied memory). This function can then be called in a loop from javascript, copying over the results to the destination. Maybe you can recycle some of the memory for the files in the next turn. (iii) A cleanup function., that closes all objects allocated and opened in (i) and maybe in (ii)

Of course, you could put it into a ReadableStream, as this is how webstreams work. The benefit would be that you can potentially decrease the memory of the Wasm build, allocate a smaller size of intermediate memory buffers, and overall, run the whole setup in less powerful devices.

Dear @martenrichter thank you for your ideas!