[Java (Android)] Thread safety vs. GC

[camelCase]

I'm taking this module which forces us to use the Android SDK, which, "yay", is in Java. I was working on a game halfway through and realized that the frame rate was dropping as I progressed, so I ran the app through a profiler and saw that it was my Vector2 math class that was causing it.

Because I have so much math going on, I also allocate a lot of Vector2 instances.. And, because Java is Java.. It's all allocated on the heap.. Which takes up a lot of memory.. And GC causes the frame rate drop..

So, I've decided to re-write my Vector2 class so that it never creates a new Vector2 instance in any of its calculations. That's half the battle.

The second half is this:

public class Vector2 {
    public static final Vector2 TmpA = new Vector2();
    public static final Vector2 TmpB = new Vector2();
    public static final Vector2 TmpC = new Vector2();
    public static final Vector2 TmpD = new Vector2();
    public static final Vector2 TmpE = new Vector2();
}

Because I have code everywhere that needs to use vectors temporarily, I decided to have some "tmp" vector2 instances allocated. Now, all of this just means that any code using TmpX will not be thread-safe. Luckily, I don't need thread-safety.

But, say, in the future, I DO need thread-safety. Is it okay to assume that this will suffice?

public synchronized void methodThatUsesTmpX () {
    Vector2 someV = Vector2.TmpA;
    //More code
}

If so, is thread-safety (by stuffing the synchronized keyword in there) or GC more efficient/better for frame-rate?

 

[s3rius]

Just to make sure: Do you know for a fact that it's the GC that kills your frame rate?

I think I remember that Java takes extra caution when allocating small objects such as a Vector2.

Making often-used function synchronized isn't such a good diea, I think. I would guess it's worse for performance than the GC (and it's certainly worse for debugging).

How about you pre-allocate a static array of a good number of Vector2s and use it as some sort of allocation pool? More memory waste, but sounds like hell of a lot better than synchronization.

But still.. is it really the allocation/dealloc of the Vec2's that kills performance?
What do those performance hot spots look like? Are you vector methods efficient? Can you cut down on allocations simply by re-defining some methods to be self-modifying instead of returning a new Vec2?

 

[Accname]

I agree with serius, synchronising those vectors would not be very effective.
I would suggest creating a vector pool for every thread. So every thread will have its own pool of vectors which you can dynamically increase or decrease in size when needed. Threads will never use the vectors of another thread, except maybe for copying data from one to another.
The copy method would need to be synchronized then.

 

[camelCase]

Strangely enough, I decided on a pool instead of synchronizing before reading the replies =x
Well, I THOUGHT it was, but it doesn't seem to be because the framerate is still not improving and all my Vector2 operations are about as efficient as, well, the original equations themselves =P

And pooling didn't work, guess it isn't better than GC.

I think I just read the profiler reading wrong. I'm not used to the Android Development Tool's way of showing profiler results =/ My draw calls seem to be taking 70% of the processing, though.

THAT is really weird because I specifically made it so that I wouldn't do any heavy processing in the draw calls. Update, 30%. Draw, 70%. Wtf. I'm using Canvas but I'm only drawing.. About 30 bitmaps and some debug texts..

 

[camelCase]

Okay, so I reviewed the profiler readings and it IS the Vector2 class. Shifted a bit more of that code and added AABB tests for the collider like s3rius recommended (what do you know, it really only took a few minutes).

My frame rate is now a good 35FPS.. Which isn't good enough. It isn't good enough because the current "game" is just three buttons, some clouds (really beautiful clouds, I assure you), a bouncing ball and platforms that appear and disappear.

And there are more things to implement. I want to keep it at 32FPS minimum when I have the entire game up and running but having 3FPS left to play around with seems.. A bit little.

I looked for the next bottleneck and..
My Camera.drawSprite() method was taking up 64.5% of the CPU time when getting 35FPS.
Looking deeper, 39.6% of that 64.5% (or 25.542% of the total CPU time) is going to Canvas.drawBitmap(), an Android call.

Looking at Canvas.drawBitmap(), Canvas.nativeDrawBitMapMatrix() is 91.5% of it. Which makes sense because I call Canvas.drawBitmap(Bitmap, Matrix, Paint);

My game's update() takes up only 14.2% of the total CPU time (that is, every single operation in the update call, which isn't a lot at the moment).
My game's draw() takes up 84.9% of the total CPU time.

So, I guess that's the thing to optimize =/

Anyone got resources for optimizing draws for Android using the SDK?

 

[Accname]

Isnt there any alternative graphics libraries for Android?
Or perhaps forums which are for android developers where you can ask people who know this stuff much better?

 

[camelCase]

Hmm..
I guess you're right =x

Thanks.
[EDIT]
Nevermind..
I just realized what was wrong =/
It had nothing to do with my code (or, at least, very little).

It's just.. My phone. My phone is always laggy.. And..
I just restarted my phone (for an unrelated issue) and noticed that my frame rate is now 63 per second..

Fuck. I stressed out so much over it when my it was my phone's hardware all along.
"Have you tried turning it off and turning it back on again?"

 

[tom_mai78101]

Editing the thread title to reflect on the main subject of this entire thread. If you have any questions, please be welcomed to start a conversation with me.