Re: Question about accessing Lua tables and arrays faster

[Steve Litt <slitt@...>]

On Thu, 25 Jul 2013 08:00:00 -0700 (PDT)
Leo Romanoff <romixlev@yahoo.com> wrote:


> - Many high-performance applications work intensively with arrays.
> Currently, Lua uses the same datatype, namely tables, for both arrays
> and maps. Accessing arrays from Lua is not extremely fast currently.
> (Lua interpreter does not use even those lua_rawseti/lua_rawgeti
> functions, IIRC. Only C libs for Lua can do it). It would be nice to
> have a faster way of operating on arrays in Lua.
> 
> BTW, I did some experiments where I create an array of 1000000
> elements and then perform a 1000 iterations over it, touching each
> element and assigning a new value to it or incrementing its current
> value. I implemented the same algorithm in pure Lua, as a C library
> for Lua which uses lua_rawseti/lua_rawgeti, and as a C program. The
> outcome is that pure Lua solution is the slowest, the C library for
> Lua is roughly 1.5 times faster and C version is about 14.5 times
> faster than pure Lua solution. 

Hi Leo,

Comparing any interpreter to C is certain to yield disappointing
results. A better test would have been to compare pure Lua to Perl
arrays, Python lists, and whatever Ruby uses for arrays (I long since
forgot). If *those* are faster than Lua in the algorithm you mention,
then we have something to talk about.

But I don't think they will be. My understanding is that Lua was
engineered from the ground up so that tables are lightning fast,
whether the keys are strings, consecutive integers, or something else.
Even if the Lua "everything's a table" philosophy yields a small speed
disadvantage over the other "scripting languages", the huge authoring
benefits of a single container type would be worth it, at least to me.

SteveT

Steve Litt                *  http://www.troubleshooters.com/
Troubleshooting Training  *  Human Performance