lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


It was thus said that the Great Viacheslav Usov once stated:
> On Thu, Feb 24, 2022 at 11:53 PM Roberto Ierusalimschy
> <roberto@inf.puc-rio.br> wrote:
> 
> > Statically-linked packages are already served by preload, you should not
> > need a new searcher for that.
> 
> This may be only slightly related to the original topic, but, in
> general, preload works well only when the number of static libraries
> is small and the act of preloading is not costly. To illustrate costly
> preloading, consider luasocket: it is a mix of C and Lua modules. When
> they are really fully embedded statically, that means the Lua files
> are also embedded (as original strings or pre-compiled byte code) and
> to be "preloaded" those strings or byte code must actually be loaded
> into the new Lua VM, memory allocated, etc. When you have
> preload-costly embedded libraries, or just really many embedded
> libraries and many Lua VMs in your application, you have to consider
> the cost of preloading, it may have a noticeable effect on
> performance.

  Having done this for work (well, not embedding luasocket, but I have a
custom build of Lua with 81 modules built in, 34 of which are in C, and 47
in Lua), I haven't noticed any appreciable different in speed from running
the normal Lua interpreter.  Lua modules in Lua have to be "compiled" in
either case.

  But as always, it may be worth measuring for what you are concerned about
before selecting on a method.

  -spc