Re: LuaJIT2 and lua_dump()

[Joshua Jensen <jjensen@...>]

----- Original Message -----
From: Mike Pall
Date: 3/2/2010 9:10 AM
> Joshua Jensen wrote:
>    
> > Additionally, fragmentation of memory will be kept at a minimum
> > as parsers almost always need scratch space.  The Lua parser does,
> > anyway.
> >      
> I've recently made some major changes to the parser that mostly
> eliminate fragmentation. It uses temporary, shared, growable
> structures which are later copied into compact prototype objects.
> All data of a prototype is colocated in memory, too. It's a single
> blob, not the 8 blobs that Lua needs per prototype.
>
> If I ever get around to it, I could additionally compress the
> debug info to 1/5th of its current size.
>    
Sounds like a nice optimization.
> > It works for code, too.  I just tested running luac on a 15k .lua ASCII
> > script.  It ended up being 7k in binary form.
> >      
> Someone on the list did a comparison some time ago. AFAIR the gist
> of it was that you'd certainly want to compress either one, if you
> really want to save disk space. And source code compresses much
> better, eating up any savings from the use of a binary format.
>    
I just tested this:

134 megabyte ASCII .lua file compressed with zip: 18 megabytes
26 megabyte binary .lua file generated from 134 megabyte ASCII 
compressed with zip: 10 megabytes

If I'm loading that data off of DVD for a console game, I just lost a 
minimum of full second bringing in and decompressing the larger ASCII 
file.  When console manufacturers have certification requirements where 
loads must happen within a certain time period, every second is at a 
premium.

In any case, I'm just providing use cases.

Josh