2
\$\begingroup\$

For obvious reasons, allocating memory on the fly in Android game development is not recommended. For example:

http://developer.android.com/training/articles/perf-tips.html:

There are two basic rules for writing efficient code:

  • Don't do work that you don't need to do.
  • Don't allocate memory if you can avoid it.

I'm following this advice and am avoiding any memory allocation whilst the game is in progress; however, it's limiting my approach to certain tasks. Whilst I could change my code to see what happens, there's a fair amount of it, and it's not going to tell me about the resulting performance on anything other than the limited range of hardware I have available to test it on.

I was wondering if there are any general rules of thumb which can provide an insight into this problem, such as how much allocation/deallocation you can get away with; whether it's the individual size of the allocation or the overall amount that's most important; things you can do to mitigate against the problem (I'm assuming the problem is chiefly having the garbage collector kick in and damage performance, and/or insufficient memory being available if it doesn't fire frequently enough); does it affect some versions of Android more than others, etc.

Improve this question
\$\endgroup\$
10
  • \$\begingroup\$ Which language? \$\endgroup\$
    – Ben
    Oct 19, 2014 at 23:02
  • \$\begingroup\$ @Ben Just updated tags; Java, and OpenGL. Toyed with writing the whole thing in C++ but having seen the performance so far that doesn't seem to be necessary. \$\endgroup\$
    – user5196
    Oct 19, 2014 at 23:09
  • \$\begingroup\$ Well, C++ is a lot more open to managing your own memory. Not only does Java often force you into dynamic allocation, but it's hard to have a guarantee about when it's freed. If you need to manage memory very carefully, C++ or even maybe C is the way to go. HOWEVER, I'd say don't worry about it. You just said that the performance isn't a problem. The only tip I could really give you with java is to try to allocate in bigger chucks( allocate 100 integers in 1 'new' rather than 100 'new's ). But I assume you probably already do that. \$\endgroup\$
    – Ben
    Oct 19, 2014 at 23:16
  • \$\begingroup\$ @Ben Currently I allocate exactly nothing on the fly. I've pre-allocated an array of objects, and so when I need a new one in game I just iterate through that array for the first "dead" one, set it to "alive" and use it. I do this with particles too. I mean, for particles it would be insane to allocate/free tens/hundreds of 10 or 20 byte objects per frame, but less stupid to allocate a handful of 100 or 200 bytes objects. \$\endgroup\$
    – user5196
    Oct 19, 2014 at 23:24
  • \$\begingroup\$ @Ben So I'm trading the more or less constant time iterating through a number of arrays to create/process the objects they contain against the presumably much more uneven iteration through a list of dynamically allocated objects. I've never allocated memory in C/C++ and subsequently used it from Java (other than with OpenGL FloatBuffers and the like) although I am competent in C++; is it possible (ie to subsequently use the memory as if you'd done it via a call to new?) \$\endgroup\$
    – user5196
    Oct 19, 2014 at 23:24

1 Answer 1

Reset to default
3
\$\begingroup\$

In my experience with android, it is the garbage collection the kills the performance, not the allocation, although these two are tied hand and hand. As mentioned on the comments, pre-allocation is a way to deal with this issue. This is known as a memory pools. Another similar solution is object pool pattern. An object pool allocates as needed, but does not immediately destroy an object. If an object is needed and an old object is still alive, the old object is issued. this saves on the allocation and destroying of a frequently used, short lived objects.

In both cases, the objects are checked in and out of the pool, so you are never creating or destroying the objects yourself.

This object pool example is a generic pool, which you can use to create a pool for any object type.

Improve this answer
\$\endgroup\$

You must log in to answer this question.