Dear All,
[this question is probably related to the "Hash Key Specialisation” section
(empty) in the wiki]
[the only archive I found (2009) is about LJ 1.1.5, so conclusions are probably
obsolete for 2.1]
I have a recurrent needs to store hidden information in users’ reachable
objects (tables) or to fully control access to data stored. So the common
approach is to associate a table to a hidden key in user’s object, where I can
manage the hidden information or store the user’s data to keep the control
through mm overriding.
The question is about using a contant local table address or a constant string
as the hidden key:
<table case, strong>
local var = {} — local to object module not accessible to user
local MT = {
__index = function (self, key)
return self[var][key]
end
}
<string case, similar to table case>
local var = ‘<$__’.. tostring({}) ..‘__$>' — random improbable string
local MT = {
__index = function (self, key)
return self[var][key]
end
}
<constant string case, weak>
local MT = {
__index = function (self, key)
return self.__var[key]
end
}
The constant string approach is always very well optimised by LuaJIT (always
constant, almost zero overhead), but the table-as-key approach allows to fully
protect the hidden variables from the user (with some more code and mm
overriding). The strings approaches are weaker and can be broken by accident if
the string is known (more difficult in the second case). So up to now I was
favouring the table-as-key approach.
On micro benchmarks I don’t measure difference probably because LuaJIT detects
the constness of the table address… So I am wondering if (constant, never
changed) table-as-key (1st case) is always as efficient as constant
string-as-key (3rd case)? I am asking about how LuaJIT optimisation works given
that the address is constant in my code but nothing to prove it to LuaJIT, i.e.
could it failed to detect it and generates a true hash lookup?
Best,
Laurent.
--
Laurent Deniau http://cern.ch/mad
Accelerators Beam Physics mad@xxxxxxx
CERN, CH-1211 Geneva 23 Tel: +41 (0) 22 767 4647
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
