Quick Links: Download Gideros Studio | Gideros Documentation | Gideros community chat | DONATE
Software Improve - What kind of skills do you need? — Gideros Forum

Software Improve - What kind of skills do you need?

HubertRonaldHubertRonald Member
edited May 2014 in General questions
Hi folks

I've seen the next links about how you can improve memory leak or performance it of your app:
http://giderosmobile.com/forum/discussion/4736/sprite-inheritance-and-memory-managment/p1
http://giderosmobile.com/forum/discussion/3711/box2d-object-with-spring/p2
http://giderosmobile.com/forum/discussion/1937/do-gideros-call-collectgarbage-occasionaly/p1
http://giderosmobile.com/forum/discussion/2087/have-destroyed-method-in-core-class/p1
http://giderosmobile.com/forum/discussion/773/scenemanager-and-managing-memory/p1
http://giderosmobile.com/forum/discussion/2141/hundreds-of-lua-files-and-performance-/p1
http://giderosmobile.com/forum/discussion/2394/memory-memory-memory-/p1
http://giderosmobile.com/forum/discussion/4142/quick-lua-gcmemory-question/p1
http://giderosmobile.com/forum/discussion/2645/help-with-memory-leak/p1

I know you can not have the technical baggage of someone who has studied computer science or software engineering, magically, if you do not prepare of course.

I am taking this course Algorithms: Design and Analysis, Part 1 and well I'm seeing that I can improve my way of programming and thereby increase the performance of my codes and with it memory of it.

I wish someone expert on programming topics can advise me (gradually) I should study to improve codes. Something like a roadmap.

I really appreciate the time than you spend in this post, because I think it will also help developers who are starting in this fascinating world.

Thanks my best :)>-

Comments

  • ar2rsawseenar2rsawseen Maintainer
    edited May 2014
    As I know you need it for your app, here are some overall tips to improve performance

    1. Packing textures
    As when drawing GPU need to swap files to draw on each enter frame, then the lesser graphical files you have the better, thus it is better to pack them in single texture.

    But on the other hand there are hardware limitations, that does not allow some GPUs to render large texture files, so best size (for scale ratio 1 using Automatic Image Scaling) is 1024x1024, try not to exceed it for your app to work on any older device

    So basically you need to balance the graphics, by packing them to texture packs and not exceeding 1024x1024 for one texture pack

    2. Memory allocation and garbage collection
    In Lua garbage collection is actually quite heavy and doing it often may result in performance drop, so usually the best practice is to reuse the created objects, so you would not have to 1) allocate new memory 2) garbage collect it
    So for example the wrong example is:
    for i = 1, 10 do
        local bmp = Bitmap.new(Texture.new("image"..i..".png"))
    end
    The right example is:
    local bmp
    for i = 1, 10 do
        bmp = Bitmap.new(Texture.new("image"..i..".png"))
    end
    So instead of creating a variable, allocating memory and then collecting it 10 times, we reallocate the memory without garbage collection penalty

    And especially if you use some kind of bullets, with box2d bodies, etc, don't destroy them, reuse them

    Here is the simple object pool for reusing:
    Pool = Core.class(Sprite)
     
    function Pool:init()
        self.pool = {}
    end
     
    function Pool:createObject()
        local b
        --if there is anything in pool take it
        if #self.pool > 0 then
            b = table.remove(self.pool)
        else --create new object
            b = Bitmap.new(Texture.new("image.png", true))
        end
        --return object
        return b
    end
     
    --instead of destroying object, put it back to pool
    function Pool:destroyObject(b)
        b:removeFromParent()
        table.insert(#self.pool, b)
    end
    3. Other Lua coding practices
    Here are a lot of best lua usage practices, as redeclaring global variables or properties as local variables, which will benefit if you are using them a lot in the scope, as the look up will be much lesser (only on one level)

    http://www.lua.org/gems/sample.pdf

    And here are some good tips here:
    http://stackoverflow.com/questions/154672/what-can-i-do-to-increase-the-performance-of-a-lua-program

    4. LuaJIT (Premium feature)
    if you do a lot of calculations on Lua level (loops, math, lots function calls, deep class nesting) not C level (as box2d physics), then most probably your app can benefit from LuaJIT, which enables running Lua code at native speed.

    This does not require any coding, but simply changing lua binary files in exported project

    5. Off screen culling or Tilemap usage
    Especially if you have large worlds, then even the objects outside the screen still consume resources.
    One way would be to disable rendering on them, by calling setVisible(false) on Sprites or groups or removing them from stage hierarchy. You could implement some world boundary checking, etc

    But the other way is using Tilemap for large worlds, as Tilemaps are really optimized and does not render outside the screen saving lots of resources, they are the best for large off screen worlds.




    These are the few coming to mind, if I remember anything else, will update the post ;)
    +1 -1 (+3 / -0 )Share on Facebook
  • HubertRonaldHubertRonald Member
    edited May 2014
    Wow amazing help @ar2rsawseen

    I am learning about big-Oh and divide and conquer algorithms (it's useful), but I am having a big headache with recursion :-??

    for example in this code I got it next:
     
    function tablet(a,b)
    	if b>0 then
    		tablet(a,b-1)
    		print(a,"x",b,"=",a*b) -- this line'll change in the next code sample
    	end
    end
     
    tablet(4,5)
     
    --[[
    4	x	1	=	4
    4	x	2	=	8
    4	x	3	=	12
    4	x	4	=	16
    4	x	5	=	20
    ]]
    but if I put "print" before than "tablet" I got it next:
    function tablet(a,b)
    	if b>0 then
    		print(a,"x",b,"=",a*b)  --changed
    		tablet(a,b-1)
     
    	end
    end
     
    tablet(4,5)
     
    --[[
    4	x	5	=	20
    4	x	4	=	16
    4	x	3	=	12
    4	x	2	=	8
    4	x	1	=	4
    ]]

    Why? :-? For me understand the last is important because this may further improve my codes in my apps

    Also I've seen than @atilim in a post suggested that in "init.lua" you should write the next to improve the speed before releasing your app:
    http://giderosmobile.com/forum/discussion/1344/is-device-testing-slower-than-final-app/p1
    function print()
    end
    would be nice if you could put this suggestion in your post above like summary

    Thanks again
  • @ar2rsawseen Those knowledge / tips above should be added in Gideros documentation page too.
    +1 -1 (+2 / -0 )Share on Facebook
  • ar2rsawseenar2rsawseen Maintainer
    edited May 2014
    @HubertRonald
    Well in the first case we firstly reach the end of recursion and and then starting to print out values on our way back:
    tablet(4,5)
        tablet(4,4)
            tablet(4,3)
                tablet(4,2)
                    tablet(4,1)
                        tablet(4,0)
                        return
                    print(4,1)
                    return
                print(4,2)
                return
            print(4,3)
            return
        print(4,4)
        return
    print(4,5)
    return
    In the second case you print out values while you are going deep into recursion:
    tablet(4,5)
    print(4,5)
        tablet(4,4)
        print(4,4)
            tablet(4,3)
            print(4,3)
                tablet(4,2)
                print(4,2)
                    tablet(4,1)
                    print(4,1)
                        tablet(4,0)
                        return
                    return
                return
            return
        return
    return
    But honestly, I really doubt the learning complex algorithms will improve much in the game (unless you are really doing some complex stuff in the game and math does not count)

    And from performance stand of point, while recursion may provide really elegant solutions, simple loop is usually faster, so don't over complicate things and do in loop what you can do in the loop :)

    Likes: HubertRonald

    +1 -1 (+1 / -0 )Share on Facebook
  • Thanks @ar2rsawseen for your tips

    But honestly, I really doubt the learning complex algorithms will improve much in the game (unless you are really doing some complex stuff in the game and math does not count)

    And from performance stand of point, while recursion may provide really elegant solutions, simple loop is usually faster, so don't over complicate things and do in loop what you can do in the loop :)
    about the last point than you said, I going to keep this in my mind.
    Thanks again for your time :)>-
  • ar2rsawseenar2rsawseen Maintainer
    @HubertRonald how's that for optimization? Looking from your game, it should help you increase performance and fps ;)

    http://giderosmobile.com/forum/discussion/1552/is-auto-cull-happens-when-sprite-is-out-of-view#Item_11

    Likes: HubertRonald

    +1 -1 (+1 / -0 )Share on Facebook
  • Thanks @ar2rsawseen
    I am getting significant savings, but the engine is quite extensive and there are several things I have to sort without altering the logic. I hope to finish in the shortest time. Thanks again :)>-
  • Yes after time another time, I also improved my program execution with this tip:
    local myClass = Core.class(Sprite)
     
    function myClass:init(conf) ... end
    function myClass:function_001()
    .
    .
    .
     
    return myClass
    so you can exclude from execution "myClass" and when you really need it in some lua file
    you only put:
    local myClass = require "myPathproject/.../myClass"
     
    local config={}
    config.x, config.y=... 
    local Object = myClass(config)
    .
    .
    .
    I hope this also helps

    Likes: MoKaLux

    +1 -1 (+1 / -0 )Share on Facebook
Sign In or Register to comment.