Re: Custom Lua Binary Sizes

[Frank Kastenholz <fkastenholz@...>]

On 1/5/18 2:07 AM, Paige DePol wrote:

> I was wondering at which size would the Lua binary be considered "too large"
> for embedding and the like. I am going to guess that this really would just

In the past when working on embedded systems which included Lua, O(1M) 
would not have been considered a significant problem, we had 10's of
megabytes of RAM, plus the stuff we had to add around the base Lua made
it in the 750k-1M range. Otoh, other systems would have had a problem
adding that to the executable.

For the environments I was dealing with, execution performance was the
critical metric. This was a bigger problem in Lua because base lua's
compiler does not do any form of optimization ... and too many
programmers assume that the compiler will do it all and the programmer
does not need to think about code structure, etc, w.r.t. performance.

The general rules of thumb are 1) each target will have a different
definition of "too much" and 2) the bigger you make it, the fewer
the number of targets that can adopt it.

I've not looked at your code, nor do I know the features you've added,
but in general, is it possible to partition your additions so that they
can be selected (via #define INCLUDE_FEATURE_X sorts of statement)? I
could easily imagine some specific environments wishing some features,
not all. In the system I was working on we were going to have to
remove some library functions (IO and OS stuff primarily) for security
and application partitioning reasons ... being able to simply
#define DONT_DO_FILE_FILE_IO would have been nice.

> For embedded systems the parser/lexer could just be left out, obviously this
> would require all necessary Lua code be pre-compiled (another good reason
> for adding cross-platform bytecode genereration to 'luac' in my opinion). I
> was also wondering if people who embed Lua precompile the source or not?

Like others we looked at precompilation and decided it was not a win.
The savings in space was not significant enough to make it worthwhile
and the compiler runs fast enough that the time compiling was not a
notable problem.  Otoh, ensuring that lua bytecode was portable
across all our potential target systems (different word sizes,
host operating systems, processor architectures & endianness, etc)
would have been a major hassle.

Frank