is that possible compile all lua files to .a and link to nginx ?

[Payne Chu]

reference the link 
http://stackoverflow.com/questions/11317269/how-to-compile-lua-scripts-into-a-single-executable-while-still-gaining-the-fas

seems luajit2 available compile lua files to .a and link to the executable.

can I do the same to compile my lua files and link with openresty's nginx ? 

I still trying but no luck yet.

[Yichun Zhang (agentzh)]

Hello!

You can do this in OpenResty but the steps require minor adjustments
to make this work.

See the detailed documentation below:

https://github.com/chaoslawful/lua-nginx-module#statically-linking-pure-lua-modules

Thanks Mike Pall for the help here.

Best regards,
-agentzh

[Payne Chu]

Thanks agentzh :D~ really great and love you guys and this platform.

[Payne Chu]

I read the tutorial already :)~

But still have one question.

Can I combine those .o files to .a file and link the .a file to OpenResty's Nginx ?

just like http://stackoverflow.com/questions/11317269/how-to-compile-lua-scripts-into-a-single-executable-while-still-gaining-the-fas

ar rcus libmyluafiles.a *.o

Because I have a lot of lua files and if need to put them all to --with-ld-opt seems will too long and trouble to manage the generating script.

[Yichun Zhang (agentzh)]

Hello!

On Fri, Nov 22, 2013 at 12:21 AM, Payne Chu wrote:
> Can I combine those .o files to .a file and link the .a file to OpenResty's
> Nginx ?
>

Yes, sure! But it also requires minor adjustments :)

I've updated that documentation section to reflect this usage:

https://github.com/chaoslawful/lua-nginx-module#statically-linking-pure-lua-modules

To quote: "

If you have just too many .o files, then it might not be feasible to
name them all in a single command. In this case, you can build a
static library (or archive) for your .o files, as in

ar rcus libmyluafiles.a *.o

then you can link the myluafiles archive as a whole to your nginx executable:

./configure \
--with-ld-opt="-L/path/to/lib -Wl,--whole-archive -lmyluafiles
-Wl,--no-whole-archive"

where /path/to/lib is the path of the directory containing the
libmyluafiles.a file. It should be noted that the linker option
--while-archive is required here because otherwise our archive will be
skipped because no symbols in our archive are mentioned in the main
parts of the nginx executable."

Thanks Mike Pall again for the technical support here :)

Regards,
-agentzh

[arthurx]

Hello agentzh, may I ask what is the performance implication of the above statically compiled lua modules versus the ordinary JIT compiled code? 

Is it the case that our ordinary lua code (say access_by_lua_file) would be JIT compiled when it is first called, that the performance gain of the above static compilation only matters for the first call? If not what percentage of performance gain should we expect to see using the above method?

Arthur



agentzh於 2013年11月23日星期六UTC+8上午5時48分12秒寫道：

[Justin Cormack]

On 29 Nov 2013 15:58, "arthurx" <fc2...@gmail.com> wrote:
>
> Hello agentzh, may I ask what is the performance implication of the above statically compiled lua modules versus the ordinary JIT compiled code? 
> Is it the case that our ordinary lua code (say access_by_lua_file) would be JIT compiled when it is first called, that the performance gain of the above static compilation only matters for the first call? If not what percentage of performance gain should we expect to see using the above method?

It is just a bytecode compilation not a JIT compilation so this makes no significant difference.

Justin

> --
> You received this message because you are subscribed to the Google Groups "openresty-en" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to openresty-en...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Yichun Zhang (agentzh)]

Hello!

On Fri, Nov 29, 2013 at 7:58 AM, arthurx wrote:
> Hello agentzh, may I ask what is the performance implication of the above
> statically compiled lua modules versus the ordinary JIT compiled code?

It's just that the server startup time could be reduced because you
save the time for Lua source to LuaJIT bytecode translation. It may be
a big win when you have a lot of Lua code to load. But you don't have
to statically link the compiled LuaJIT bytecode. You can just put the
bytecode into separate external files, like .luac files :)

It has nothing to do with JIT compilation because JIT compilation can
only happen when interpreting the bytecode, which is way after the Lua
source to bytecode translation.

Whether your Lua code is actually JIT compiled is a complicated
question. But you can see all the details by using the jit.v library
shipped by your LuaJIT installation (or OpenResty installation) by
putting the following snippet into your nginx.conf's http {} block:

init_by_lua '
local verbose = false
if verbose then
local dump = require "jit.dump"
dump.on(nil, "/tmp/lj.log")
else
local v = require "jit.v"
v.on("/tmp/lj.log")
end

-- require "resty.core"
';

The output of the LuaJIT JIT compiler can be seen in the /tmp/lj.log
file but you need to query your Nginx a bit first to make code hot
(because JIT compilers only compile hot code).

BTW, you can use the lua-resty-core library and uncomment the require
"resty.core" line above to make more of your Lua code JIT compilable
because ngx_lua's default Lua API based on the classic Lua C API
cannot be JIT compiled at all.

Regards,
-agentzh