Android Assets file size affects performance?

SDL Development
1

This may not be an issue with SDL, but since I have no way to test it outside of SDL’s environment, I’d like to hear other people’s experience of this issue.

Loading from files in the assets folder (with SDL’s file interface) works like a dream until a single file reachers near to 5mb, then there’s a very noticeable delay of about quarter of a second each time any data is read from the file. The performance hit isn’t graudal; it seems to go from no delay to noticeable delay at about 4.5mb+.

I’ve read that there’s a 1mb limit for asset files, which was resolved to no size limit since Android version 2.3.

Anyone had any similar experience with this or have any idea as to why there’s a performance hit after a certain size?

I can solve this by breaking up data into 1mb segments anyway, but that’s a pain, especially when I shouldn’t need to.

All I can think of is that the assets stored in the .zip are cached when accessed, and Android’s java engine fails to cache zipped files of a certain size, but I can’t find any info about this.

2

Hi,

my experience is that it depends whether the asset file is only “stored” or
"compressed" when embedded in the .apk

During build of the .apk, some files in the asset folder are only stored,
based on file extensions. E.g. a “.png” file is just stored, bust most files
will be compressed.

I had a much better experience with performance of asset files, when I
started renaming them to .png and thus avoided the compression :slight_smile:

Regards,

Daniel

---------- P?vodn? zpr?va ----------
Od: AntTheAlchemist
Komu: sdl at lists.libsdl.org
Datum: 12. 9. 2015 2:03:36
P?edm?t: [SDL] Android Assets file size affects performance?

"

This may not be an issue with SDL, but since I have no way to test it
outside of SDL’s environment, I’d like to hear other people’s experience of
this issue.

Loading from files in the assets folder (with SDL’s file interface) works
like a dream until a single file reachers near to 5mb, then there’s a very
noticeable delay of about quarter of a second each time any data is read
from the file. The performance hit isn’t graudal; it seems to go from no
delay to noticeable delay at about 4.5mb+.

I’ve read that there’s a 1mb limit for asset files, which was resolved to no
size limit since Android version 2.3.

Anyone had any similar experience with this or have any idea as to why
there’s a performance hit after a certain size?

I can solve this by breaking up data into 1mb segments anyway, but that’s a
pain, especially when I shouldn’t need to.

All I can think of is that the assets stored in the .zip are cached when
accessed, and Android’s java engine fails to cache zipped files of a certain
size, but I can’t find any info about this._______________________________________________
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org"

3

I thought that, but when I looked inside the .apk, my asset file is already uncompressed anyway. Maybe because it contains PNG files, or it’s over a certain size? I don’t know. The extension I use is res.

I’m guessing the Dalvik engine has a limited space where it holds assets in memory so they don’t have to be extracted (irrespective of needing to be decompressed) from the .apk every access, and I’ve hit that limit?

I’m about to re-engineer my .res database so it splits the compacted resource files in 1mb chunks, and see if that works.

4

Splitting my asset file into smaller byte size chunks cured the problem. It doesn’t seem to matter if assets are zip compressed or not - I notice no great performance hit on compressed assets compared to uncompressed assets.

So the problem was accessing an asset file greater than about 5mb causes a half-second pause on each call to SDL_RWread() on that file. Reduce the file size down to 4.5mb and there’s no pause. A difference of 1 byte can make the difference a half second pause to no pause. So it’s something to do with a java engine cache limit per file, it seems. The affect seems to be the same on several different android devices.

Interesting to note that during the apk build, asset data files are sometimes compressed and sometimes not, depending on their compression ratio. Anything above about 20% compression is compressed and anything under seems to be stored instead.

5

Hi

I have ported a commercial SDL based game to Android and while doing so,
I also came to the conclusion that the Java/Dalvik based ZIP handling is
simply too slow.

I decided to take the awesome PhysicsFS[1] (Thanks Ryan!) library and
added a hack[2][3] to allow the lib to use the APK files.
Using the SDL_RWops glue code provided by PhysicsFS this solution is
easy to integrate and provides a greatly improved performance.

Maybe this approach can save you from splitting your resource files into
1MB chunks?

Regards,
Reto

1: https://icculus.org/physfs/
2: https://bugzilla.icculus.org/show_bug.cgi?id=6144
3: https://bugzilla.icculus.org/show_bug.cgi?id=6398On 09/15/2015 01:52 AM, AntTheAlchemist wrote:

So the problem was accessing an asset file greater than about 5mb causes
a half-second pause on each call to SDL_RWread() on that file. Reduce
the file size down to 4.5mb and there’s no pause. A difference of 1 byte
can make the difference a half second pause to no pause. So it’s
something to do with a java engine cache limit per file, it seems. The
affect seems to be the same on several different android devices.