Re: Quality-of-Life patches

[Olexa Bilaniuk <obilaniu@...>]

On Tue, Mar 1, 2022 at 6:15 AM Viacheslav Usov <via.usov@gmail.com> wrote:
>
> On Fri, Feb 25, 2022 at 8:09 PM Sean Conner <sean@conman.org> wrote:
>
> > > 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.
>
> Performance is not just speed, it is also storage.
>
> > Lua modules in Lua have to be "compiled" in
> > either case.
>
> This remark makes me wonder what your baseline really was.
>
> Certainly the cost of compiling 47 Lua modules vs not compiling them
> at all should be measurable. Then, of course, this cost should be
> viewed in the perspective of what else your Lua states are doing.
>
> I was thinking about a situation when a Lua state (VM) may end up
> using only a small number of preloaded modules, and when its "main"
> payload might be relatively light and short-lived. If all your Lua
> states always use all of the preloaded libs, or stay on doing some
> heavy lifting, then, sure, the act of preloading has a negligible
> run-time cost.
>
> Cheers,
> V.

My reasoning behind implementing a "static searcher" and adding it to
the searchers table rather than a loader was exactly Viacheslav
Usov's. If you have a number of Lua contexts, each doing their
specialized tasks relying on a few modules, it seems wasteful to
compile for all of them KLOCs of Lua code they will never use.



Olexa Bilaniuk