lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On 5 June 2015 at 20:46, Brigham Toskin <brighamtoskin@gmail.com> wrote:
> This is pretty nice if you have to manipulate subsections of a sequence
> frequently, and want to conserve memory. Is there a big performance hit for
> accessing through a slice rather than the table itself?

No, as the slice directly accesses the data of the table it points to.
It is actually faster than performing row/column calculations and
accessing the parent table.

I guess couple of things help.

The int and float arrays in Ravi specialize the Lua table type - the
data for such arrays is held in a native C double or integer array -
not as Lua Value array. As far as standard Lua is concerned the table
is empty! But of course all the table API routines in Ravi are
modified so that the array appears as normal table when accessed in
Lua (except that only certain operations are permitted).

Apart from the fact that storing arrays natively allows various
operations to be performed on them in C code - for example the array
contents could be passed to a C++ sort function - this has the added
benefit that as far as Lua GC is concerned there is nothing to collect
in these arrays. I have not benchmarked yet but I would expect some
savings in GC cycles when many such arrays are being created and used.

The second reason is that the array indexing operation for these types
is inlined in Ravi - so that means when a slice accesses an array
element  it is not going via a function call. So the data is directly
accessed.

There is a bounds check unfortunately with every access so the access
is not as cheap as in C.

Regards