'Lua.refs' grows unbounded when executing function on js object

[t-mw]

I'm experimenting with using lua.vm.js to run scripts multiple times per second (game application). The scripts execute functions stored on javascript objects, but this seems to cause LuaVM.Lua.refs to grow larger after each script iteration, which affects performance.

Although the number of non-null elements in LuaVM.Lua.refs remains constant, since the array grows larger and larger, the time taken to execute indexOf here becomes increasingly long.

I've prepared a reproduction below, demonstrating how the length of LuaVM.Lua.refs increases proportionally to the number of script iterations, and that this increases the time required to execute subsequent scripts. If my approach to calling functions outside of the vm could be improved, I'd appreciate any advice.

var LuaVM = require("lua.vm.js");

var vm = new LuaVM.Lua.State();


var obj = {
    test1: function() {
        return 0;
	},
    test2: function() {
        return 0;
    },
    test3: function() {
        return 0;
    },
    test4: function() {
        return 0;
    }
};

vm.execute("obj = ...", obj);
for (var i = 0; i < 1000; i++) {
    vm.execute("return obj.test1()");
    vm.execute("return obj.test2()");
    vm.execute("return obj.test3()");
    vm.execute("return obj.test4()");
}

console.log("1000 iterations - ref count: " + LuaVM.Lua.refs[vm._L].length);

benchmark("benchmark", function() {
    vm.execute("return obj.test1()");
});

for (var i = 0; i < 10000; i++) {
    vm.execute("return obj.test1()");
    vm.execute("return obj.test2()");
    vm.execute("return obj.test3()");
    vm.execute("return obj.test4()");
}

console.log("20000 iterations - ref count: " + LuaVM.Lua.refs[vm._L].length);

benchmark("benchmark", function() {
    vm.execute("return obj.test1()");
});

function benchmark(desc, fun) {
    console.time(desc);
    for (var i = 0; i < 10000; i++) {
        fun();
    }
    console.timeEnd(desc);
}

[daurnimator]

A fix for this limitation could be using a Map in browsers where it is supported.

[t-mw]

That looks like it solves the bottleneck: t-mw@e7c935d. Maybe Map can be polyfilled in other browsers, but I'll use my own build for now.

Thanks for all the work you've put into the project, by the way!

[daurnimator]

Map usually gets polyfilled with .indexOf; so you'll be back to square one there :p

Looking at your commit though: you didn't exactly fix the issue: you'd have to use two maps (or use the same one twice): once to map from id => object. and once to map object => id.
This saves you from iterating the whole map to find your object.

[t-mw]

you'd have to use two maps (or use the same one twice): once to map from id => object. and once to map object => id.

Only around ~20 references are kept in the map in my case so iteration is quick, but I don't know how it would look for other use cases. The main benefit for me was to avoid iterating over the unused elements that were building up.

Map usually gets polyfilled with .indexOf; so you'll be back to square one there :p

Ah, ok. That would be important for the two map approach; for the iteration a normal javascript object could be dropped in.

[daurnimator]

FYI, core.js has a shim for Map that doesn't use .indexOf.