Re: [ANN] Haxe Lua : compile Lua/LuaJIT script from Haxe 3.3

[stepa alimov <stepa.alimov.93@...>]

> Can you tell me cases where reflection causes problems for you?

Objects with proxy metatables are slightly slower.
This (https://gist.github.com/Stepets/6e079bb6163718208d5ad21191710931) simple bench shows that.
My results:
average time without metatable
init:    0.01016667    modify:    0.01614811
average time with metatable
init:    0.01118717    modify:    0.01936691

This (https://gist.github.com/Stepets/35097b0dc9ecbf90adb0843dcd5eb907) bench shows arrays lenght field update impact

My results:
average time original metatable
init:    0.00510624    modify:    0.00062112
average time simple metatable
init:    0.00358827    modify:    0.00064114
average time without metatable
init:    0.00047244    modify:    0.00064349

I'm using lua5.2

2016-05-29 16:33 GMT+03:00 Justin Donaldson <jdonaldson@gmail.com>:

P.S. Can you tell me cases where reflection causes problems for you?  I can probably simplify haxe object structures if I detect Reflect is not being used.

Also, a bunch of new static analysis features were added pretty recently that removes some of the iife structures I was generating.  You should see fewer and fewer of those.

On Sun, May 29, 2016 at 3:15 PM, Justin Donaldson <jdonaldson@gmail.com> wrote:

The cached class concept is great idea.  I know the _javascript_ target uses a similar method, and I'll look into making it a default for lua.  FWIW, you can easily generate "humanized" static method names with the @:export("new_method_name) metadata on the respective field.

On Sun, May 29, 2016 at 2:05 PM, stepa alimov <stepa.alimov.93@gmail.com> wrote:

Hello, Justin!

> I'd really like to get feedback from the Lua folks here on the structure/performance of the Lua generated code

I've worked a bit with this generator and what I can say:

in-place increment, decrement operations converts into (function() ... end)() this is good, but not always necessary.
Some AST preprocessing could be made to detect if return of this operations are required. What I mean:

var i = 2;

i++;

print(i);

now converts into something like:

local i = 2

(function()

local hx_tmp = i

i = i + 1

return hx_tmp

end)()

print(i)

Also, long chain of table field dereferencing generates on calls, and this is major performance issue IMO.

Consider we have class Foo in package com.app.super.my.package1.package2.package3.Bar

Then, each call to static field of this class will look like

local instance = com.app.super.my.package1.package2.package3.Bar.Foo.new()

as you can see, there are 9 table lookups

For my work project I've changed generator to produce "cached" classes, so class declaration looks like:
com.app.super.my.package1.package2.package3.Bar.Foo = _hx_new();
local com_app_super_my_package1_package2_package3_Bar_Foo =
com.app.super.my.package1.package2.package3.Bar.Foo

Along with removing stuff needed for reflection (code I converting doesn't use this). I've got about 2 times performance boost.

I'm using lua5.2 as target, but under LuaJIT with and without jit-compilation 2-times boost also persists.

Hope my feedback was helpful and thanks for your great work!

2016-05-29 14:16 GMT+03:00 Justin Donaldson <jdonaldson@gmail.com>:

Hi folks,

I recently wrote a Lua target for the Haxe language: http://haxe.org/blog/hello-lua

I think it has a lot of promise for building more sophisticated Lua apps (e.g. Nginx/lua + Redis/lua + _javascript_/html5/ios), while also granting the ability for those apps to integrate with other languages and frameworks.

The target is still considered to be in beta mode, but passes our extensive unit test suite.  I'd really like to get feedback from the Lua folks here on the structure/performance of the Lua generated code, and how I might better provide extern support (e.g. Haxe doesn't support multiple returns, which I know is a major sticking point at present.)

I hope some of you find it to be useful!

--

С уважением, Алимов Степан Геннадьевич.

--

С уважением, Алимов Степан Геннадьевич.