 |
lua-l archive |
|
|
||
|
|
Thanks for the various replies guys, that was very useful. You even answered a question I had been wondering about, but I hadnt included in my original post. I had also been Googling for "Lua Source code strippers", but hadnt found anything relevant. The last word in the Google search, triggered some interesting search results though. I am having a little play with LuaSrcDiet just now. Regards Geoff > Date: Fri, 22 Apr 2011 00:20:09 +0200 > From: dirk.feytons@gmail.com > To: lua-l@lists.lua.org > Subject: Re: Discussing Lua compiling > > On Thu, Apr 21, 2011 at 20:30, Fabien <fleutot+lua@gmail.com> wrote: > > I regularly run Lua on an embedded system (ARM9). Changing the compiler into > > a cross-compiler is easy, even in our case where we had to modify the > > bytecode format (to allow execution from flash). > > As for gains linked to precompiling: > > > > with a bit of tuning you can run the bytecode straight from flash, thus > > saving some RAM > > Lua itself use very little stack space (coroutine stacks are allocated in > > the heap). The compiler, however, can consume quite a lot of stack while > > generating bytecode, typically much more than the bytecode will use when > > interpreted. Precompiling therefore lets us reserve less RAM for the stack. > > > > In terms of speed and storage space, there is little gain to expect, > > especially if you don't strip the debug symbols. > > I recently did some measurements on our MIPS platforms. Loading > precompiled bytecode was 2.5x (unstripped) to 4x (stripped) faster > than compiling the scripts at load time. In absolute numbers this > meant that initializing a new Lua state and loading some basic modules > dropped from 140 ms to 54 ms and 34 ms respectively. > > In certain cases there's a user on the other side waiting for response > so this reduction in loading time is most welcome for us. > > -- > Dirk > |