LuaJIT startup performance

[Luís Eduardo Jason Santos]

Is there a benchmark concerning LuaJIT performance on its first run (as
compared to plain Lua)?

Maybe the real question I'd like to ask is: would it hurt to run a cgi-based
application using LuaJIT?

Att.

[Mike Pall]

Post by Luís Eduardo Jason Santos
Is there a benchmark concerning LuaJIT performance on its first run (as
compared to plain Lua)?

It's slightly faster. I've timed lua_open + luaL_openlibs in
isolation. First immediately on process startup, then a second
time after closing it, to eliminate effects of cache/TLB warmup.
All times in microseconds on a 3GHz Core2 (lower is better):

1st 2nd
---------------------------
155 95 Lua 5.1.4
85 60 LuaJIT 2.0.0-beta2

But the main overhead comes from the process startup, shared
library loading and resolving the symbol stubs. This is of course
system dependent. With Linux it takes at least another 250
microseconds, even without loading readline.

The standard Lua stand-alone program is linked with readline. Just
loading the required shared libraries, without even using a single
function of them, adds a whopping 900 microseconds to the total time!

Post by Luís Eduardo Jason Santos
Maybe the real question I'd like to ask is: would it hurt to run a cgi-based
application using LuaJIT?

It wouldn't hurt. But you wouldn't see much of a difference,
either. If the Lua code for request handling is only run once,
it's probably not compiled at all. So you're not getting any
benefit from a JIT compiler.

Consider using FastCGI which eliminates the process startup
overhead. And keep the same lua_State alive across many requests,
so the Lua code can get compiled. This should give you much better
performance.

--Mike

[Petite Abeille]

Post by Mike Pall
It wouldn't hurt. But you wouldn't see much of a difference,
either. If the Lua code for request handling is only run once,
it's probably not compiled at all. So you're not getting any
benefit from a JIT compiler.

While at this conjuncture the JIT itself doesn't make much of a difference for a typical Web app, the VM does:

% lua -v Nanoki.lua . 0 1080
Requests per second: 773.17 [#/sec] (mean)
% luajit -v Nanoki.lua . 0 1080
Requests per second: 1174.19 [#/sec] (mean)
% luajit -v -joff Nanoki.lua . 0 1080
Requests per second: 1167.37 [#/sec] (mean)

http://article.gmane.org/gmane.comp.lang.lua.general/58851

Also, if the "CGI" type launcher supports persistent connections by reusing a process for the lifetime of a connection, then one might benefit from the JIT itself at some point.

[stefan]

This post might be inappropriate. Click to display it.

[Luís Eduardo Jason Santos]

Post by Luís Eduardo Jason Santos

Post by Luís Eduardo Jason Santos
Maybe the real question I'd like to ask is: would it hurt to run a

cgi-based

Post by Luís Eduardo Jason Santos
application using LuaJIT?

It wouldn't hurt. But you wouldn't see much of a difference,
either. If the Lua code for request handling is only run once,
it's probably not compiled at all. So you're not getting any
benefit from a JIT compiler.
I know, but there are some cases where there are a number of repetitive

tasks to be performed, and I just wanted to have these cases covered in case
there was nothing to lose for the ordinary cases.

Post by Luís Eduardo Jason Santos
Consider using FastCGI which eliminates the process startup
overhead. And keep the same lua_State alive across many requests,
so the Lua code can get compiled. This should give you much better
performance.
I know, but as I need to install in several environments, I'd like to keep

most possibilities open (and CGI is the most problematic in terms of
performance).