Re: [ANN] LuaDist Batteries 0.9.7

[Coda Highland <chighland@...>]

On Thu, Oct 25, 2012 at 3:07 AM, Peter Drahoš <drahosp@gmail.com> wrote:
>
> On 25 Oct, 2012, at 8:58 , steve donovan <steve.j.donovan@gmail.com> wrote:
>
>> On Wed, Oct 24, 2012 at 3:34 PM, Peter Drahoš <drahosp@gmail.com> wrote:
>>> A minimal binary version of batteries-0.9.7 is available for Windows that does not contain any documentation, examples, tests or other optional files (it still contains license files). Additionally all binaries have been striped and packed using UPX. This package is most suitable starting point for distribution of Lua based applications to end users.
>>
>> Good work, Peter!  A big effort indeed.
>>
>> Just a small point: do we gain much from UPX-packing, seeing as
>> usually we would pack as a compressed archive?
>
> In context of the minimal release the reduction of size is rather significant. UPX reports reduction to about 30% of the original size for almost all binaries. Some libraries (most notably libwx of wxwidgets) are reduced to a fraction of their original size (12MB to about 2.3MB). For the 1.0 release I will only UPX pack the minimal release, other releases will only be stripped to avoid the false positives on some antivirus software. This should satisfy most requirements as sometimes the reduced size is beneficial for some end-users (including myself).
>
> Some data: (Windows only)
> Release 0.9.1 - 74.8MB, no IUP, only stripped
> Release 0.9.7 - 45.7MB, UPX packed
> Minimal Release 0.9.7 - 14.5MB, UPX packed, no optional files
>
> pd

Keep in mind that UPX packing also means that the executable has to
unpack itself at runtime, which increases startup delay, plus the
executable still needs to be unpacked SOMEWHERE which means either
more disk space (temporary file) or more RAM is necessary, and it also
means that multiple running instances can't take advantage of sharing
read-only pages in memory.

UPX may have made more sense when storage devices were smaller and
slower and it was cheaper to decompress at runtime than to wait for
the increased amount of data to be read from disk. Now it's just
additional overhead. The one place where size still matters (download
sizes) you can use better compression algorithms on an archive.

/s/ Adam