3

In my code I need to keep track of certain value (a string, always...) in a local. I'd like to know whether the run time will re-create or examinate this string after putting it in a local, on the official Lua 5.3 implementations. Any ideas? In this lua.org document I've at least heard the Lua implementation does string internalization (keep a single copy of any string).

I'm restarting my code, so I've done insignificant things so far. An example of what I might do per function is:

local src = l[1]

-- `src` would hold a string
iehrlich
  • 3,572
  • 4
  • 34
  • 43
  • 1
    AFAIR PUC-Rio lua-5.3 does not intern short strings anymore. Also, Lua 5.3 and LuaJIT are two completely different things. – iehrlich Jul 18 '17 at 23:02
  • 5
    Also, it's absolutely unclear what you are trying to achieve. Seriously, could you be just a little bit more clear, maybe with some additional code, and what you expect it to do? – iehrlich Jul 18 '17 at 23:03
  • @iehrlich Sorry, well... I'd expect this code to not be expensive during run time, but my question is whether it'll copy the string or not inside the value of my local. I expect it'll directly point the string. I thought of asking this to the Lua team too (by e-mail), but I doubt I'd get quick answers. –  Jul 18 '17 at 23:06
  • 1
    Ah ok, that's a nice question – iehrlich Jul 18 '17 at 23:07
  • 2
    Since strings in Lua are immutable there will always only be a single reference to each string. – Henri Menke Jul 18 '17 at 23:21
  • @HenriMenke I see. I'd be kinda afraid if Lua didn't do that –  Jul 18 '17 at 23:24
  • 3
    @iehrlich, Lua 5.3 does internet short strings. – lhf Jul 18 '17 at 23:25
  • @lhf yes, it does, just took a look at the code. An interesting decision though. – iehrlich Jul 18 '17 at 23:35

1 Answers1

2

If the strings are interned or not is actually not a concern - string interning is simply a mechanism to speed up string comparisons and (probably) spare some memory at the expense of CPU needed to create a string.

What matters is the fact that strings in lua are what is usually called reference types. This is, runtime values only hold and share references to the strings, and assigning a string to a runtime value is simply copying a pointer and setting up proper tag for this value.

Another thing your code does, is it allows you to avoid multiple hash lookups during the execution of your function. For example,

local a       = tbl['mykey']
-- ...
local other_a = tbl['mykey']

will result in two hash lookups, while

local cached_a = tbl['mykey']
-- ...
local a = cached_a
-- ...
local other_a = cached_a

will reduce it to one lookup. But yet again, this is usually not a big deal for integer keys. But sometimes even integer keys trigger hash lookups, even if they are small. Also, it's implementation dependent. Lua is very simple.

iehrlich
  • 3,572
  • 4
  • 34
  • 43
  • Thanks xd I did also read Lua uses an array for sequence fields (1, 2, 3, and so on), and additionally, for avoiding `nil` problems I predefine some like `local NULL = {}, NULLF = false`. LuaJ (another implementation in Java used in TFM) also uses arrays to avoid hash. Though there's an optmization inline-caching used in LuaJIT (another implementation) –  Jul 18 '17 at 23:37
  • 2
    @Matheus Array+hash implementation of tables is the only viable option according to the Standard. The only thing that might vary is the balancing rule (decision on where the array part ends). Also, it's possible that LuaJIT is able to eliminate a number of consequent hash lookups to the same table with the same key, but that's another story. – iehrlich Jul 18 '17 at 23:41