[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LuaJIT2 and lua_dump()
- From: Joshua Jensen <jjensen@...>
- Date: Tue, 02 Mar 2010 09:40:08 -0700
----- 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,
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
In any case, I'm just providing use cases.