Description
~~~~~~~~~~~
I have around 100 files that represents around 450 Mo to load a game. I'm not parsing anything, just loading raw data (ByteArray).
Problem
~~~~~~~
On desktop using File, loading all resources takes 46 seconds.
I was thinking that the 100 file access could be the cause of the problem. So I tried to use one unique archive, and uncompress it using Fzip, that way it would reduce 100 file access to one. To load the whole archive it took 61 seconds, 15 seconds longer. (Normal decompression takes 4.7seconds, I'm not sure how much time and resource it takes for FZIP, I didn't check it source yet)
Being on desktop environment equipped with a SSD hard drive, I find this time surprisingly long. And as you can imagine it's 10 times slower on mobile devices, which s a real problem for user experience.
Question:
~~~~~~~~~
Has Flash some kind of disk access speed restriction?
Is there any alternative to solve my problem?
Ok I finally got compression and fast loading ... 5 seconds for 450 mo with adl 8-20 seconds on android tablet three years old.
.
Short answer:
~~~~~~~~~~~
I found that by pure chance, I didn't dug into the why.
ditto -c -k --rsrc --extattr --keepParent public public.zip
zip public.zip public
.
Long answer:
~~~~~~~~~~~
On my original post, and original compression test, I was basically using mac compression that uses ditto and again took 45 seconds with adl.
I was curious about trying with zip and 0 compression, so without removing the old archive, I did a simple zip command, the archive size didn't change an inch, and suddenly i got 5 seconds loading ...
I then removed the archive, and redo the simple zip command, archive was ~450 mo, and the game wouldn't load the archive at all.
I did the tests several time, and just reproduce the three case above ... I'm quite sure there is a simple explanation behind all this, and I think it might be possible to manage all that with only one command line instead of two. Right now I just don't have time to dig more in an explanation, but I might come back later on this.