Module talk:table

Lua insertion efficiency

@Erutuon What the source for the claim that t[#t + 1] = v is more efficient than table.insert(t, v)? I've looked before, but had trouble finding it. I also want to ensure that the former method goes into the array and not the hash table. —JohnC5 21:37, 20 September 2017 (UTC)

@JohnC5: I recently ran across a few places where it was mentioned. Before, I thought it was a silly way to add a key when there was a neater-looking function. One source is the Lua wiki, the other is the Civilization Fanatics Forums. The latter mentions that it's even faster to assign table length to a local variable and increment it, so perhaps we should do that wherever possible.

I don't know if the values are inserted into the array part of the table. (I feel like I've seen conflicting information on whether Lua has arrays, so I'm confused.) Apparently local t = { [1] = "a", [2] = "b", [3] = "c" } does not add the values to the array part, according to this. But I'm not sure if local t = {}; t[1] = "a"; t[2] = "b"; t[3] = "c" would behave the same way, or the above t[#t + 1] = v. What also puzzles me is that C arrays require stored values to be a specific size, while Lua arrays do not, so I am not sure how the Lua arrays would be or are implemented. Meh. — Eru·tuon 02:54, 21 September 2017 (UTC)

@Erutuon: I've confirmed that t = {}; for i = 1, 5 do t[#t + 1] = i end; for i, j in ipairs(t) do print(i) end has the desired behavior, so whatever. —JohnC5 03:12, 21 September 2017 (UTC)

@JohnC5: I've implemented the fastest option from the forum link above. It doesn't affect memory, but it might make the previews of Lua-heavy pages load faster. (Hard to test Lua time usage on Wiktionary because it's so fickle.) — Eru·tuon 04:14, 21 September 2017 (UTC)

Protection

@JohnC5: I learned when I made a dumb error that this module is required for a huge number of templates now. It should probably be template-protected so that a random person doesn't edit it and fill Wiktionary with module errors. — Eru·tuon 04:12, 29 November 2017 (UTC)

Changing contains() and insertIfNot() to use deepEquals()

@Erutuon I've thought about it and come to the conclusion that contains() and insertIfNot() should use deepEquals() regardless of the `deepCompare` option. I'm planning to make this change, but since it could have far-reaching implications, I wanted to check with you first. The reasoning is that:

1. I think it's rare that the shallow comparison behavior is desired. Deep comparison by default is consistent with the principle of least surprise.
2. Having shallow comparison as the default is likely to introduce subtle errors: Callers won't think about the need to explicitly enable deep comparison, and failing to deep-compare won't usually cause a module error, but instead will cause incorrect behavior.
3. Deep comparison for operations like these is consistent with the way other programming languages and libraries work.
4. I think it's unlikely to break anything, since I can't actually think of a real use case where it's wrong to do deep comparison. At worst it will make certain operations slower.
5. Lua modules are much more likely to run out of memory than to hit the 10-second timeout limit, and switching to deep comparison won't increase memory usage; deepEquals() doesn't create any objects.

My plan is to introduce new functions called shallowContains() and shallowInsertIfNot() that do shallow comparison, and change contains() and deepEquals() to ignore the `deepCompare` flag and always do deep comparison with deepEquals() (not deepEqualsList() as is currently done, which doesn't make much sense). In case this causes module timeouts, we can switch the appropriate places to call the shallow versions; but I don't expect this to happen. Benwing2 (talk) 06:38, 28 December 2021 (UTC)

@Benwing2: The change should be fine because contains is generally used on arrays of simple types, not on arrays of tables, and it's pretty rare for Wiktionary modules to want to check equality of table references. (Module:grc-utilities does here, but that's the only case I can recall and contains isn't involved.) I did some basic experiments on a memory-tracking version of Lua 5.1 and recursive non-tail function calling does allocate memory, but hopefully an insignificant amount. — Eru·tuon 08:25, 30 December 2021 (UTC)