PDA

View Full Version : Performance on Android hardware including OUYA



WILL
28-07-2013, 08:52 PM
Recently I've come to suspect just how well Oxygene for Java's output byte-code performs on actual Android devices. My interests lay specifically with OUYA in my case, but has anyone done any tests or benchmarks to see how it would compare to say Eclipse or other Java language based compilers?

WILL
05-08-2013, 07:36 AM
I should have expected silence. ::)

SilverWarior
05-08-2013, 08:40 AM
Not many pascal developers own OUYA yet.

Now if you want I belive I still have source code for several of my trivial applications which I used for testing various aspects and could actually serve as benchmarking tools like data sorting, multithreading thests, chached file copying (not using default OS file buffer), masively creating/destroying classes, overloading processor for testing system stability, file read rate test, and probably some more.

pstudio
05-08-2013, 08:40 AM
*First of all Eclipse is "just" an IDE which uses the default compiler from JDK.* Not Correct!!!

I haven't done any such tests yet, but I haven't been programming for a while as well. I'm planning on starting a new project with Oxygene which may be ported to the OUYA. There I might do a few tests to compare javac vs Oxygene.
Otherwise you could do it yourself and share the results ;)

phibermon
05-08-2013, 03:49 PM
First of all Eclipse is "just" an IDE which uses the default compiler from JDK.

I always think I sound like a complete jerk when I correct people but please understand it's for all that would read the topic, not anything specifically targeted at your good self :)


Eclipse has it's own compiler that is seperate from javac.

http://stackoverflow.com/questions/3061654/what-is-the-difference-between-javac-and-the-eclipse-compiler


--

I should imagine that performance is much the same across the board. I'd expect the native javac and eclipse compilers to produce marginally faster code than Oxygene.

As with FPC vs Delphi or GNU C++ vs Micrsoft C++, code structure is most important and choice of compiler when concerning performance is only a consideration if you're maxing out your target device. As you'd be aware of the most performance intensive games available for your target devices you can make a rough estimation of how 'busy' they are and design your own games to hover below those requirements to account for any slight performance penalty that may exist with Oxygene etc

pstudio
05-08-2013, 06:50 PM
I always think I sound like a complete jerk when I correct people but please understand it's for all that would read the topic, not anything specifically targeted at your good self :)


Eclipse has it's own compiler that is seperate from javac.

http://stackoverflow.com/questions/3061654/what-is-the-difference-between-javac-and-the-eclipse-compiler



Well turns out I'm the jerk :D I did not know that Eclipse sports its own compiler. Just assumed it would use javac.

WILL
06-08-2013, 05:36 AM
Not many pascal developers own OUYA yet.

Our performance issues extend to any Android based platforms so even if you information is just about Android devices, it'll help. The only difference may be that OUYA is a quad-core.

Well our game is not using object pooling, and we have to put it in, but I'm wondering if that may be a bigger problem than we think. The game does create and destroy objects, but not consistently. How much of a performance hit can your game take while you are not creating or destroying objects without the object pooling implemented?

Are there other memory management issues such as Garbage Collection kicking in at other times for other reasons?

SilverWarior
06-08-2013, 06:48 AM
Well our game is not using object pooling, and we have to put it in, but I'm wondering if that may be a bigger problem than we think. The game does create and destroy objects, but not consistently. How much of a performance hit can your game take while you are not creating or destroying objects without the object pooling implemented?

Based on documentation I read about Object pooling it laregly depends on what kind of a bocjets are you using.
If you are using objects which are only stored in memory (have no external resources) the Object Pooling may actually be slower. Why? On returning the object into object pool you need to reset it state to initial one manually.
So if your object contains lots of variables you need to change every one of them to some starting value. Now you can skip reseting every varable state to some initial but this could in some cases lead to unexpected behavior.


Are there other memory management issues such as Garbage Collection kicking in at other times for other reasons?

Also based on Object pooling documentation using it can make Garbage Colection procedures take longer time.

Also, most garbage collectors scan "live" object references, and not the memory that these objects use for their content. This means that any number of "dead" objects without references can be discarded with little cost. In contrast, keeping a large number of "live" but unused objects increases the duration of garbage collection.[1] (http://www.pascalgamedevelopment.com/#cite_note-urban-1) In some cases, programs that use garbage collection instead of directly managing memory may run faster.

Also the main problem in Object pooling is that you need seperate pools for each object type. ANd to make most out of it you need to predict the optimal number of pooled objects and this I belive is far from being easy in a computer game.


Now if you are concerend with memory usage of your game I suggest that you first try to implement data sharing approach (mutiple objects share same common data).
For instance you have your ingame unit whose class loks like this:

TMonster = class(TObject)
private
FHealth: Integer;
FMaxHealth: Integer;
FName: ShortString;
FDescription: String;
FPosition: TPosition;
FOrientation: TOrientation;
FAttack: Integer;
FSpeed: Integer;
end;

You can quickly see that some of the data from that class is being duplicated for every created object. So to reduce the memory requirement you actually split that class into two seperate ones.
One that holds the often changing data:

TMonsterDynamic = class(TObject)
private
FHealth: Integer;
FPosition: T3DPosition;
FOrientation: TOrientation;
FMonsterData: TMonsterStatic;
protected
function GetMaxHealth: Integer;
function GetName: ShortString;
function GetDescription: String;
function GetAttach: Integer;
function GetSpeed: Integer;
public
property MaxHealth: Integer read GetMaxHealth;
end;

function TMonsterDynamic.GetMaxHealth: Integer;
begin
if FMonsterData <> nil then
result := FMonsterData.FMaxHealth
else result := 0;
end;
And the one that holds often static data:

TMonsterStatic = class(TObject)
FMaxHealth: Integer;
FName: ShortString;
FDescription: String;
FAttack: Integer;
FSpeed: Integer;
end;

This can reduce the memory consumption a lot especially when you have large number of objects.
I'm writing a detailed tutorial on using this approach but unfortunately I'm not sure when it will be finished. I hope soon.

pstudio
06-08-2013, 07:42 AM
Our performance issues extend to any Android based platforms so even if you information is just about Android devices, it'll help. The only difference may be that OUYA is a quad-core.

Well our game is not using object pooling, and we have to put it in, but I'm wondering if that may be a bigger problem than we think. The game does create and destroy objects, but not consistently. How much of a performance hit can your game take while you are not creating or destroying objects without the object pooling implemented?

Are there other memory management issues such as Garbage Collection kicking in at other times for other reasons?

GC starting to do its work is a problem in game development on managed platforms, especially Android/Dalvik. When I've looked around most people advice not to create and free resources during gameplay. It is considered a slow process on Android and at some point the GC will begin and possibly make your game lag for a little while.

As SilverWarrior writes it's true that Object pooling is not the right answer in all cases, but for a real-time apps on an Android device I believe pooling is often worth doing.
Another advice regarding GC is to call it after initialization of a game and before and after gameplay to try and prevent the GC from starting during gameplay.