BitmapFrontEnd.hx, getUniqueKey performance

[Shinzo25]

• Flixel version: 3.3.11
• OpenFL version: 3.3.2
• Lime version: 2.6.1
• Affected targets: Android, Flash

---

Code snippet reproducing the issue:

public function getUniqueKey(?baseKey:String):String
{
    if (baseKey == null)
        baseKey = "pixels";

    if (checkCache(baseKey))
    {
        var inc:Int = 0;
        var ukey:String;
        do
        {
            ukey = baseKey + inc++;
        }
        while (checkCache(ukey));
        baseKey = ukey;
    }
    return baseKey;
}

---

I am making a puzzle game in which i am pre-creating 1024 FlxText objects.
Using Timer.stamp(), i was able to figure that each getUniqueKey in FlxText's new function holds around 0.002s, which means the 1024 takes around 2 seconds. It might not be that long but on android and on some low-end tablets, it can be very long.

I don't have a good understanding of how the internals of flixels work or what the next change will imply but here it goes :

public static var LatestInc:Int = 0;

public function getUniqueKey(baseKey:String = "pixels"):String
{
    if (checkCache(baseKey))
    {
        var inc:Int = LatestInc;
        var ukey:String;
        //ukey = baseKey + LatestInc++;
        do
        {
            ukey = baseKey + inc++;
        } while (checkCache(ukey));

        LatestInc = inc;

        baseKey = ukey;
    }
    return baseKey;
}

This gave me a 0.3s launch time.

I'm worried that internaly this affects something badly and i won't know it, thus me posting here.

First time posting on github, so...yeah, sorry for any problems or mistakes

[Gama11]

This takes ~0.9s for me on Neko:

package;

import flixel.graphics.FlxGraphic;
import openfl.display.BitmapData;
import flixel.FlxG;
import flixel.FlxState;

class PlayState extends FlxState
{
    override public function create():Void 
    {
        haxe.Timer.measure(function()
        {
            for (i in 0...1024)
            {
                FlxG.bitmap.add(FlxGraphic.fromBitmapData(new BitmapData(1, 1), true));
            }
        });
    }
}

That's definitely way more expensive than it should be.

[Gama11]

I optimized it a bit, now down (including your proposed change) to 0.3s on Neko debug, but that still seems a bit much for just 1024 iterations...

[Shinzo25]

Thanks for the help.

I didn't try to go deeper than the getUniqueKey for optimization. So, i really don't know where else there is room for optimization.

For flash, with the old BitmapFrontEnd, it was 1.2s. With the new one, it's 0.3s.

Atleast now i know it's safe to use :).

[Beeblerox]

i'll try to use array instead of map for caching and will compare perfomance tonight

[Gama11]

Hm... Why do you think an array would be faster? I think it could be slower in some cases actually.

[Beeblerox]

yes, in some cases it would be slower, but it will generate less garbage in other (like iterating over all elements).
i just want to try it :)