RE: Trying to understand some Lua Internals ?

Hi

Thanks for the reply Matthew, I finally got around to investigating the long delay in closing the Lua state.

I should have guessed that Lua was being nice and efficient :)

If I close the Lua state it was taking over 8 seconds to complete. If I did the same thing but with the single line mem_free call to my OS commented out the time dropped to 0.15 Seconds. I was surprised how marked the difference was, I havent really worked around the problem yet, but at least I know who the culprit is now

Regards Geoff

> From: mwild1@gmail.com
> Date: Sun, 8 Jan 2012 18:42:19 +0000
> To: lua-l@lists.lua.org
> Subject: Re: Trying to understand some Lua Internals ?
>
> On 7 January 2012 13:02, Jeff Smith <spammealot1@live.co.uk> wrote:
> > Hi
> >
>
> >
> > The timings seem to suggest that is not the way it works? I am complelely
> > guessing here now, but the other possibility is that when the subsequent
> > lua_pcall() function runs, it must load the require files and compile to
> > bytecode at that point, before it runs the bytecode. If that is the case,
> > when are the require files loaded, always right at the beginning of pcall()
> > or does it depend on where they are placed in the Lua source ?
> >
>
> require() is a function like any other function. Compiling a script
> (loadfile) does not execute any functions, it just compiles them to
> bytecode. Therefore, yes, you are on the right track - require()'d
> modules will not be loaded until the pcall.
>
> > Issue 2)
> >
> > While I was timing some functions I also measured the time to create the
> > lua state and open the standard Lua libs and my custom library bindings.
> > This took about 200 mS, that is roughly what I would have guessed and no big
> > deal. I then also measured the time to execute the lua_close(L)
> > line. Slightly to my horror this took 8 seconds ! In my system I need to
> > stop and start the Lua task quite often, so this very sluggish close time is
> > a nasty problem.
> >
> > I was anticipating the garbage collector destroying objects to be quite
> > complex and slow, but didnt think it would be that bad. From a peruse of the
> > code it looks like it traverses a linked link of objects and then frees them
> > one at a time from the system memory pool. I put some debug code in to try
> > and understand what is going on, it would seem that the lua_close() function
> > triggers the destruction of over 4000 objects, (so is taking approx 2mS per
> > object to free)
> >
> > If I measure the amount of object freeing for a single line print("Hello")
> > Lua program I get
> >
> > objectFrees[LUA_TNIL]=0
> > objectFrees[LUA_TBOOLEAN]=0
> > objectFrees[LUA_TLIGHTUSERDATA]=0
> > objectFrees[LUA_TNUMBER]=0
> > objectFrees[LUA_TSTRING]=593
> > objectFrees[LUA_TTABLE]=101
> > objectFrees[LUA_TFUNCTION]=595
> > objectFrees[LUA_TUSERDATA]=3
> > objectFrees[LUA_TTHREAD]=0
> > objectFrees[LUA_TPROTO]=2 // Anyone know what a TPROTO is, I
> > cant guess what that one is ?
>
> It's the bytecode for a function (shared by all Lua function objects
> that are based on the same code).
>
> > Total objectFrees=1,294 (this is about 400 for a standard Lua build with
> > no custom libraries)
> >
> > So that is pretty big too, closing the lua state for a do nothing program
> > would probably take 2.6 seconds or so.
> >
> > Any thoughts on these numbers, do these object counts look plausible ?
>
> I don't have any code to test or time to produce code to test, but I
> can say it's quite a bit higher than I would have expected for a plain
> Lua state. I can't say it's wrong though, without anything else to go
> on.
>
> In general it sounds like you're on a platform with constrained
> resources. Take a look at eLua, which is Lua heavily tweaked to run
> efficiently on low-power devices.
>
> Regards,
> Matthew
>