[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [Experiment] Module system based on static hashing
- From: Stefan <ste@...>
- Date: Sat, 18 Apr 2020 15:31:07 +0200
Am 17.04.2020 um 01:17 schrieb Sean Conner:
> I have a similar issue at work, although it's not speed reasons but
> installation reasons (the less files to install, the better). To that end,
> I created what I call the Kitchen Sink Lua executable, which includes *all*
> the modules we use at work.
I feel like many people would like to have Lua + extra modules
bundled into one executable (especially for Windows).
It's just that everybody needs different "extras" and doesn't
want the rest...
At startup, I load all the luaopen_*() calls
> into package.preload (these are listed in a luaL_Reg[] arraay) and add a
> special loader to package.searchers to load the modules in Lua (that are
> compiled via luac, compressed [1] and stored in the executable; the loader
> finds the appropriate data and decompresses it when lua_load() is called).
Did you create it manually or with a script?
> Each was run 10,000 times and the runtime (and memory, obtained from
> lua_gc()) averaged. No special compiler options were used but I think this
> is enough to give us some ballpark figures. The base (just state creation
> and deletion) used 2K and gives us a baseline to compare the rest. The
> minmin case (just loading package and leaving the rest to be require()ed)
> took almost three times as long and amost 3 times the momory. The min
case
> took almost four times as long, and 3 times the memory. And the full case
> ... well ... 9 times longer and 7 times the memory.
>
Looks congruent to my results.
This linear growth with the amount of functionality added is
the problem. Suddenly the script isn't as small and lightweight anymore.
And require()ing on a per-function basis isn't a solution, IMO.