Re: Lua 5.4-work1 with first class arrays (implementation & benchmarks)

[Dirk Laurie <dirk.laurie@...>]

2018-03-31 8:20 GMT+02:00 Petri Häkkinen <petrih3@gmail.com>:

> The concept of freezing arrays is interesting. But as a side-effect to table.resize() it’s misleading. Perhaps there should be a new function or metamethod for freezing the array.

The point is that array length might not be known before
initialization of an array is complete, and that the order in which
elements are initialized might not just be t[#t+1] = whatever. But
once the array is initialized, an out-of-bounds element is probably a
bug, so an explicit resize is necessary.

But if table.resize on a non-array is already doing something, then
obviously it can't be used for another purpose.

So really your patch is doing two things:

1. Providing arrays.
2. Tuning performance of non-arrays.

I got the following benchmark results:

$ lua5.4 benchmark1.lua
Running benchmarks using tables...
Insert           0.666199s
Write            1.111530s
Read             0.750843s
Push             3.401312s
Scatter-write    0.363270s
Scatter-read     0.369240s
Length           2.622978s

$ ../lua benchmark1.lua
Running benchmarks using tables...
Insert           0.458256s
Write            0.578925s
Read             0.565197s
Push             1.629770s
Scatter-write    0.278028s
Scatter-read     0.269423s
Length           0.989217s

Running benchmarks using arrays...
Insert           0.483858s
Write            0.592988s
Read             0.560617s
Push             0.585361s
Scatter-write    0.232693s
Scatter-read     0.229581s
Length           0.173127s

No arrays available; array benchmarks skipped!

I.e. the patch without using arrays already does quite a lot better
than work1 does; is that just because of the nature of this benchmark
or is there a good reason why that should happen in general?