В файле
ltable.c сказано следующее:
The actual size of the array is the largest 'n' such that at least half the slots between 0 and n are in use.
Таким образом, массив охватывает ключи от 0 до такого числа n, что используется хотя бы половина. Давайте ещё посмотрим на код функции
computesizes, которая решает, каким будет размер массива при изменении размера таблицы. Эта функция перебирает степени двойки (1, 2, 4, 8 ...) и смотрит, какая доля массива была бы занята, если бы он был такого размера. Останавливается, когда эта доля становится меньше половины. Нетрудно доказать, что при таком алгоритме выбора размера массива и при сплошном заполнении всех ключей от 1 до n обязательно будет выбран размер массива, больший или равный n.
Кстати говоря, из этого же следует, что при добавлении в конец массива элементов будут накладные расходы, но не на хеш-часть, а на пустые элементы массива, выделенные "про запас". Но так и должно быть, чтобы не перестраивать массив при каждом новом элементе. (В C++ vector.push_back ведёт себя так же.) Если заранее знаете окончательный размер массива и хотите на этом выгадать, то напишите сишное расширение, которое вызывает lua_createtable(L, размер-массива, 0).
По поводу того, не появится ли хеш-часть при замене значений на различные типы. Не появится. Дело в том, что в паре ключ-значение ключ и значения
хранятся в разных полях. Я отследил как используется поле i_val, оказалось только в макросе gval, тип которого нигде не фигурирует (только проверки на nil).
Кроме того, могу посоветовать использовать rawset и lua_rawseti, так как они не проверяют метаметоды, поэтому должны работать быстрее. Про lua_rawseti я уверен, что работает быстрее, а про rawset подозреваю.
