[Date Prev][Date Next][Thread Prev][Thread Next]
- 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  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
> 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.