LuaJIT
#11
Of course I know that locals are faster. If I didn't know that my plugins would be awfully slowTongue But what you're using here isn't OOP. You're just getting a static function, putting it in a variable and calling. That won't work well with actuall methods. For example, look at the code I used for my test:
Code:

local MyClass = {}

function MyClass:new()
	local Obj = {}
	setmetatable(Obj, self)
	self.__index = self
	
	Obj.TestVar = math.random(50)
	
	return Obj
end

function MyClass:Test()
	local R = self.TestVar + 50
end

local startTime = os.clock()
local Constr = MyClass:new()
for I = 1, 1000000000 do
	Constr:Test()
end
print(os.clock() - startTime);


It's a really simple example of a class in Lua. What I could do is get the "Test" function and make it a local. Then give the object as a parameter, but how are you planning on making the TestVar variable a local? It's also of course not pretty to use that.
Reply
Thanks given by:
#12
local MyClass = {}

function MyClass:new()
	local Obj = {}
	setmetatable(Obj, self)
	self.__index = self
	
	Obj.TestVar = math.random(50)
	
	return Obj
end

function MyClass:Test()
	local R = self.TestVar + 50
end

local startTime = os.clock()
local Constr = MyClass:new()
local test = Constr.Test
for I = 1, 1000000000 do
	test(Constr)
end
print(os.clock() - startTime);
Reply
Thanks given by:
#13
Yes, but you're still accessing the TestVar variable 1000000000 times from the table. It still takes 67.455 in Lua, while it takes 0.419 seconds in LuaJit.
Reply
Thanks given by:
#14
I just tested that. It was ~50 seconds while your original code was 60Tongue
Let me try to come up with some hacky way to make the other variable local too, it'd be interesting to compare. Though it would certainly not be tidied code.

This one took 9 seconds:

local MyClass = {}

function MyClass:new()
    local Obj = {}
    setmetatable(Obj, self)
    self.__index = self

    Obj.TestVar = math.random(50)

    return Obj
end

local startTime = os.clock()
local Constr = MyClass:new()
local R = Constr.TestVar
for I = 1, 1000000000 do
    R = R + 50
end
Constr.TestVar = R
print(os.clock() - startTime);

You have a point.
Reply
Thanks given by:
#15
Interestingly, this variation also took ~60 seconds even though it doesn't use tables inside the loop.


local MyClass = {}
 
function MyClass:new()
    local Obj = {}
    setmetatable(Obj, self)
    self.__index = self
     
    Obj.TestVar = math.random(50)
     
    return Obj
end
 
function Test(val)
    return val + 50
end
 
local startTime = os.clock()
local Constr = MyClass:new()
local test = Test
R = Constr.TestVar
for I = 1, 1000000000 do
    R = test(R )
end
Constr.TestVar = R
print(os.clock() - startTime);

Reply
Thanks given by:
#16
That's because it's trying to get the variable R which is inside the global table (print(_G)). If you make R a local variable it should be a whole lot faster, but I can hardly call it OOP thenTongue
Reply
Thanks given by:
#17
Whoah, I can just copy the LuaJit dll and replace it with lua51.dll. It actually worksTongue When executing my example code it was done in 0.426 seconds.

OOh, and goto's are working in LuaJitBig Grin

And even the FFI works Smile
[Image: its_working_star_wars.gif]

I also heard that raw byte code is portable across every architecture that LuaJit supports. This way people could create closed source plugins if they wanted to.
Reply
Thanks given by:
#18
@worktycho is it still really hard to use LuaJit instead of Lua? If I remember correctly you said LuaJit doesn't have an ANSI mode like Lua, but isn't the server now using Unicode since a PR made by Tigerw?
Reply
Thanks given by: jan64 , sphinxc0re
#19
That isn't the main issue. The big problems are: luaJIT is not ISO C, or POSIX, so we need to reduce our target platform support, or support both luajit and lua. Also LuaJIT has a complex build system, that hasn't been ported to cmake other than x86, so we lose the all in one build system.
Reply
Thanks given by:
#20
So it's a choice between performance and portability. Since the former is already good enough for almost all plugin use cases, the logical choice is choosing portability.
Reply
Thanks given by:




Users browsing this thread: 1 Guest(s)