Memory Management

  ... discussions about development with the GLES2 branch of AndEngine.

Re: Memory Management

Postby Mathew » Sun Jun 16, 2013 9:06 pm

RealMayo wrote:Definitely not me. I've got garbage collection happening throughout my game. What can you even do to prevent it?


Well most important principal is not to allocate memory during game-play. But still its really easy to create memory leak which will probably invoke GC.
User avatar
Mathew
 
Posts: 1073
Joined: Sun Jul 31, 2011 2:49 pm
Location: Tarnów, Poland

Re: Memory Management

Postby RealMayo » Sun Jun 16, 2013 9:34 pm

Well as you know the entire premise of Traktor Digger is based upon allocating memory at run time. :lol:
User avatar
RealMayo
 
Posts: 1694
Joined: Sat Sep 03, 2011 9:25 pm
Location: Chicago, IL

Re: Memory Management

Postby Mathew » Sun Jun 16, 2013 9:37 pm

RealMayo wrote:Well as you know the entire premise of Traktor Digger is based upon allocating memory at run time. :lol:


Why so? I am talking about not to allocate memore during game-play, and by saying game play I do not mean time while loading new levels etc, if that`s what you mean, if not, explain.
User avatar
Mathew
 
Posts: 1073
Joined: Sun Jul 31, 2011 2:49 pm
Location: Tarnów, Poland

Re: Memory Management

Postby RealMayo » Sun Jun 16, 2013 9:48 pm

Well in Traktor Digger 1 (and even more so in Traktor Digger 2) there is a lot of destroying physics bodies then recreating physics bodies during the game ;)
User avatar
RealMayo
 
Posts: 1694
Joined: Sat Sep 03, 2011 9:25 pm
Location: Chicago, IL

Re: Memory Management

Postby Mathew » Sun Jun 16, 2013 9:51 pm

RealMayo wrote:Well in Traktor Digger 1 (and even more so in Traktor Digger 2) there is a lot of destroying physics bodies then recreating physics bodies during the game ;)


Well I believe you should try to pre-create everything on beginning of the level instead of creating it latter, to get better performance, but since you are developer of your own game, I can not judge it because I have not enough info about your code and your case.

Anyway, about my mentioned single GC, I managed to spot it, thanks to allocation tracker which is just superb while trying to spot what caused GC.
User avatar
Mathew
 
Posts: 1073
Joined: Sun Jul 31, 2011 2:49 pm
Location: Tarnów, Poland

Re: Memory Management

Postby RealMayo » Sun Jun 16, 2013 9:56 pm

Since I haven't even begun to play with the allocation tracker, can you give me some tips/advice on it?
User avatar
RealMayo
 
Posts: 1694
Joined: Sat Sep 03, 2011 9:25 pm
Location: Chicago, IL

Re: Memory Management

Postby Mathew » Sun Jun 16, 2013 10:06 pm

Sure, I thought about making detailed video with example of such unnecessary allocation and fixing it on my blog, but here`s what you can do so far, you should understand it easily.

1. Inside Eclipse, press window->show view->other->android

2. open following views:

- devices
- heap (not necessary for allocation tracking, but still useful to have it while investigating)
- allocation tracker

3. Plug in your device, start your game, in the devices tab, select your device, it should expand list with running processes (anyway just click on your game process)

Image

4. Go to allocation tracker view, press start tracking (its good to type your game package name in the filter, so you can have a look strictly on yours game allocation)

5. And here`s what I do, its bit weird but that`s how it works, at least for me, in your game do some kind of task, for example I was touching my button with entity modifiers, after pressing get allocations button, I received list with performed allocations (I was creating new entity modifiers all the time, instead of using reset method to change values - that`s for example) So what I do, I simply play my game, checking various game features, and pressing get allocations button to see if there were any (its tricky, because previous allocations are going to be skipped in report so you will have to repeat certain task you suspect causes allocation) Or simply keep pressing get allocations button during game-play to track down all allocations, and than - SIMPLY (or not) get rid of them.

My example:

Image

Its good to do it inside eclipse, instead of stand alone ddms application, because you just jump directly to the file, line where allocation occurs.

:P
User avatar
Mathew
 
Posts: 1073
Joined: Sun Jul 31, 2011 2:49 pm
Location: Tarnów, Poland

Re: Memory Management

Postby e.r. » Mon Jun 17, 2013 12:09 am

You are starting to making me like the DDMS after all :D thanks for the quick tutorial : )

I finally managed to run my new game on the 20 Mbytes heap, and guess what it was after all very easy to decide weather a game can run or not (Memory wise).
1 - Read the heap of the device.
2 - loop over all the asset files that you want to load have calculate the number of pixel and multiply by 4 ( don;t forget the font atlas). the result is in bytes, compare it to the heap size and decide whether your game run or not.

I used a pure java code to test this on my reduced resource and the result was that the game started loading on the chacha when the total number of pixels to load was smaller than 20 Mbytes, and I have only created small sized resources for only 15% of the png files ! The more resource files I create, the smaller the lag becomes : )


Below is the java code to loop over the assets and get the total size in bitmaps ( the asset are thrown in a side folder for testing purposes)

Syntax: [ Download ] [ Hide ]
Using java Syntax Highlighting
  1.         public static void main(String[] args) throws IOException {
  2.  
  3.                 int totalpixel = 0;
  4.                 File dir = new File("C:/Users/e.r./Desktop/New folder (2)/");
  5.                 for (File child : dir.listFiles()) {
  6.                         BufferedImage bimg = ImageIO.read(child);
  7.                         totalpixel = totalpixel + (bimg.getWidth() * bimg.getHeight());
  8.                 }
  9.                 System.out.println("Total Pixels" + totalpixel);
  10.         }
  11.  
Parsed in 0.012 seconds, using GeSHi 1.0.8.4


PS: This does not include sound and music, which also should be taken into consideration
User avatar
e.r.
 
Posts: 557
Joined: Sun Sep 09, 2012 1:41 pm

Re: Memory Management

Postby e.r. » Mon Jun 17, 2013 12:58 am

The allocation tracker is giving that the GC are caused by the class java.lang.StringBuilder and the line of code responsible is the following:

Syntax: [ Download ] [ Hide ]
Using java Syntax Highlighting
  1. this.killNumber.setText("" + totalKills);
Parsed in 0.010 seconds, using GeSHi 1.0.8.4


1 - I am updating the HUD in particular the Text object to update the score, I have already prepared the letters in the Text object :S, any idea how this can be avoided?

2 - In addition the allocation tracker gives the the highest call, which is inside your code, it doesn't go inside AE code, to see where this object is allocated inside the setText. Any idea?
User avatar
e.r.
 
Posts: 557
Joined: Sun Sep 09, 2012 1:41 pm

Re: Memory Management

Postby nazgee » Mon Jun 17, 2013 1:02 am

code to loop over the assets and get the total size in bitmaps


This does not take ETC1 textures into account. Actually... This will not work if assets in multiple formats are used. You should probably try to take bpp into account to make it reliable.
Dirt Rider Mayhem is PUBLISHED now!
Image
User avatar
nazgee
 
Posts: 527
Joined: Fri Oct 21, 2011 10:31 pm
Location: Poland, Wrocław

PreviousNext

Return to GLES2

Who is online

Users browsing this forum: Google [Bot] and 41 guests