Results 1 to 9 of 9

Thread: Performance on Android hardware including OUYA

  1. #1
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,108
    Blog Entries
    25

    Question Performance on Android hardware including OUYA

    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?
    Jason McMillen
    Pascal Game Development
    Co-Founder





  2. #2
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,108
    Blog Entries
    25
    I should have expected silence.
    Jason McMillen
    Pascal Game Development
    Co-Founder





  3. #3
    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.

  4. #4
    *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
    Last edited by pstudio; 05-08-2013 at 06:53 PM.
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

  5. #5
    PGD Staff / News Reporter phibermon's Avatar
    Join Date
    Sep 2009
    Location
    England
    Posts
    524
    Quote Originally Posted by pstudio View Post
    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/3...lipse-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
    When the moon hits your eye like a big pizza pie - that's an extinction level impact event.

  6. #6
    Quote Originally Posted by phibermon View Post
    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/3...lipse-compiler
    Well turns out I'm the jerk I did not know that Eclipse sports its own compiler. Just assumed it would use javac.
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

  7. #7
    Co-Founder / PGD Elder WILL's Avatar
    Join Date
    Apr 2003
    Location
    Canada
    Posts
    6,108
    Blog Entries
    25
    Quote Originally Posted by SilverWarior View Post
    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?
    Jason McMillen
    Pascal Game Development
    Co-Founder





  8. #8
    Quote Originally Posted by WILL View Post
    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.

    Quote Originally Posted by WILL View Post
    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] 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:
    Code:
    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:
    Code:
    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;
    Code:
    function TMonsterDynamic.GetMaxHealth: Integer;
    begin
        if FMonsterData <> nil then
        result := FMonsterData.FMaxHealth
        else result := 0;
    end;
    And the one that holds often static data:
    Code:
    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.

  9. #9
    Quote Originally Posted by WILL View Post
    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.
    Imagine I've written something clever here inspiring you to make something awesome. If that happens give me credits

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Comodo SSL