[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Faster tag methods
- From: "Curt Carpenter" <curtc@...>
- Date: Tue, 5 Mar 2002 09:55:19 -0800
Another idea/request for the sake of performance:
I love the idea of tag methods for get/set. What I don't love is all the
string processing required in the host environment to use them in a way
where I want to match the key name against a set of known key names.
Because of this, I currently use numeric indices for all my table
elements, with variables for the numbers, like this:
FieldNameX = 1
FieldNameY = 2
...
table[FieldNameX] = x
table[FieldNameY] = y
Instead of just
table.FieldNameX = x
table.FieldNameY = y
This way in the get/set tag method, I can do a fast lookup by field
numeric id (either just a switch statement, or hash table if I get lots
of properties, which is likely). The named field method requires a lot
of string processing *every* time the tag method is called. It seems
like we can do better.
The numeric key approach is not very desirable, mainly because now all
the field names are opaque when I dump the table contents, and if we add
other elements to the table that aren't part of the known set of named
numeric keys, then we use the normal string key notation, which means we
have to keep track of which keys are strings, and which keys are named
numbers (t.x vs t[x]). In my case, I'm creating a system where people
other than myself will be writing code, so confusions like this will be
troublesome.
So, would it be possible to do something like this: Keep the reference
id on objects referenced. Then have a function like lua_toref which does
an O(1) lookup to return the reference to the top item on the stack?
Clearly this would mean that an object can only have one reference. I
don't know if we already have that limitation or not, but it doesn't
seem like a terribly inconvenient restriction.
Or maybe some other way? The main point is just to do something to avoid
string processing required to recognize string keys in table elements.
Thanks!
Curt