1

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?

  • Are you loading those files asynchronous? Loader or File? – Andrey Popov May 17 '14 at 13:46
  • Out of curiosity, could you decompress all the files on your desktop using 7zip or similar and tell us what kind of time it takes? It's probably quicker than your app, but it's worth knowing what the absolute fastest it could be done in is. If it takes 15s, you probably have nothing you can do to improve the time it takes, for instance. – Josh May 17 '14 at 15:59
  • @JoshJanusch Like I said on my original post: "Normal decompression takes 4.7seconds" – user3599123 May 17 '14 at 16:08
  • @AndreyPopov synchronously, and I'm using File. – user3599123 May 17 '14 at 16:09
  • Use `getTimer()` to track down how much time is needed to open, read and *close* the file (separately for each operation). I think there is something to do with an overflow or something, especially if you keep reference to them. This way you will know which operation costs the most. If you are sure that decompression takes less time, then maybe reading is more.. – Andrey Popov May 17 '14 at 17:49
  • One more thing - where you load the files from? They are not packed with the app, right? From which folder do you load them? – Andrey Popov May 17 '14 at 17:53
  • @AndreyPopov, they are in a folder that I packed with the app. – user3599123 May 18 '14 at 09:18
  • Well then this should be the case. The files that you put in the package are compressed, and when you load them, an internal decompression occurs. So you load the file, decompress it, then it becomes ByteArray, which you decompress again. Makes sense it's slower. Try putting those files after you've installed the app and load them from documents or cache directory and check the times. Should work properly. – Andrey Popov May 18 '14 at 09:22
  • @AndreyPopov I'm executing the game with adl, when I do my game is not packed. Also as stated on my original post, I have 46 seconds when using folder and 61 seconds when using FZIP. As a consequence, I use the folder method, thus I don't have any decompression at all in my current process, right now I'm just loading ByteArray and don't even parse it. When loading is done I trace the execution time and execute NativeApplication.exit(). – user3599123 May 18 '14 at 10:58
  • @AndreyPopov I really appreciate you try to help and I don't mean to be rude, but please note that most information you asked for are in the original post, and none of your posts are in the range of my questions (stated in the "Question" paragraph). – user3599123 May 18 '14 at 11:10
  • Well I haven't seen how you're compiling (as you said `folder that I packed with the app`), nor if you're loading them sync or not. About the File - you are right :) And I don't know how someone can help you solve the 'problem' as it's not defined.. I think you should first understand which part takes most time, and then search for a solution. I would like to hear it as well :) – Andrey Popov May 18 '14 at 13:18

1 Answers1

0

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.