[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: [ANN] Luabins — Trivial Lua Binary Serialization Library
- From: Alexander Gladysh <agladysh@...>
- Date: Mon, 23 Feb 2009 02:58:08 +0300
I wrote a small and simple library called "luabins" to serialize and
unserialize trivial Lua values (including tables) into arbitrary
binary data format. Nothing fancy, but perhaps it would be useful for
someone else. Looks like it works as intended, so I'm releasing a
first version to public.
Luabins is hosted at GitHub: http://github.com/agladysh/luabins/
You may download release 0.1 here:
Or you may browse sources online: http://github.com/agladysh/luabins/tree/v0.1
Luabins is licensed under the same license as Lua -- the MIT license.
Luabins works with nils, booleans, numbers, strings, tables (as long
as they contain only supported values and are not too deeply nested).
Luabins refuses to save and load functions, threads and userdata
Luabins provides both "clean C" (C/C++ subset) and Lua API. Here is a
little silly example in Lua:
local status, a, b, c = assert(luabins.load(luabins.save("A", "B", "C")))
print(a, b, c) --> "A", "B", "C"
Luabins primary usage intent is to serialize Lua-to-Lua RPC call
arguments. Thus save and load must be fast and resulting data must be
It seems (see BENCHMARK file in the distribution) that the current
implementation is faster than working with Lua sources from Lua in
both save and load (concatenation and loadstring). However, current
save implementation heavily abuses Lua stack for data string
generation -- this may have performance impact on complex data
structures. This issue should be alleviated in future releases.
As for the relative data size, it depends on the data nature. If, for
example, data consists primarily of small natural numbers, then
luabins format is considerably larger than Lua sources -- as it stores
each number as a double. I think I can come up with a couple of
optimizations here as well, but for a (small) cost for the save speed.
Luabins intentionally does not save or check any meta-information
(crc, versions, endianness etc.) along with data. If needed, it is to
be handled elsewhere. However, reasonable (hopefully) precautions are
taken to protect from destructive malformed data (e.g. from attempts
to force memory overruns or overallocation). (That being said, please
bear in mind that this is 0.1 alpha version; there are probably a
quite a few surprises there still.)
Questions and critique are welcome!