local v = band(1000, 7) -- given local band = bit.band
I did not say that lua is not as fast as you think, I said that some things doesn't run as fast as you think in lua.
Edit: My checking was incorrect and, although modulo is faster than bit.band, it is by a smaller margin.
This is my lastest test code:
local LOOPS = LOOPS or 10000000
local function check(test)
local band, clock, v = bit.band, os.clock
local s = clock()
for i = 1, %d do %s end
return clock() - s
print(check("v = bit.band(i, 7)"), check("v = band(i, 7)"), check("v = i % 8"), check(""))
print(check("v = i % 8"), check("v = i % 7.2"))
print(check("v = i * 6.3"), check("v = i / 5.4"), check("v = i + 6.3"), check("v = i - 5.4"))
print(check("c = i % 8"), check("local c = i % 8"))
Certainly that would be "nice", but not even in a traditional programming environment would this behaviour be mandatory to get a working cache, as long as your cached data is not collected while used (and this won't happen in Lua because there will be hard references when it's used).
I still don't know what table you're talking about, since I talked about caches and not weak tables...
Well, I'm talking about the table where you're going to put the processed data so that your lib can return the output faster the second time it's called given the same input. There's nothing else but tables in lua.
If you don't have control over the lifespan of the data in your cache, then the usefulness of the cache becomes questionable. Not using weak tables means that either you let the cache grow (which may be fine) or add some function to control and reduce the size of your cache, and it adds to the cost of the cache by itself. If the cache costs more, then its usefulness is reduced.
Well, in a cache such as the one I've just described, you want the keys to be weak and not the value.
Why ? Because the reason you're keeping a cache is that you want to respond faster to the caller's requests. If the keys are weak (but not the value), then the control of when the data is collected goes to your caller. Which is exactly what you want. As long as they need you to do your stuff on data X, they have a reference to X somewhere that prevents your cache entry to be collected and your cache is efficient. Otherwise, you just have no idea, and you might as well have no cache or keep the data ad vitam æternam.
The issue is that you loose any control on when the data will be collected if you set your cache's __mode to "v" or "kv".
You have a cache that use source data as a key and calculated results has a value. Obviously, the only place the calculated results are kept is in the cache, so they are always candidate to be collected if you set your cache to have weak values. Thus they will get collected at the end of the next collection cycle, regardless on wether or not is useful. The garbage collector controls when your data disappear, not you.
Okay, based on that, my advice is not to cache. If all you want is to modify a tooltip when the user ask for it, then do it when the user ask for it, and don't keep it. Look at the code in Ratings, that I wrote. Ratings doesn't cache anything at all.
One thing you need to be careful about is spells in item tooltips. Basically, items can have any of the base attributes, armor and ratings. The rest is provided by spells. One thing about spells attached to items is that the string that appears in tooltips is written by hand, so typos or alternative formulation is definitly going to occur (and think about non enUS languages, where they tend to occur a lot more). This is even worse for spells that add several attribute values, like gems.
Caching with string keys doesn't work as you hope it does. lua will not collect weak tables with string keys.
Sadly, good performance is definitely required for what I have planned.
And what is that ? There is no way I can possibly think of were you want to scan a significant number of tooltips, unless you let the user choose when you do, and that's just means it won't matter that much because users will do it when they have the time.
Otherwise a different caching method than LIB uses... (LIS uses per-tooltip caching. This prevents problems when showing tooltips from links vs. tooltips from inventory, mixing them in the cache would be fatal)
What does that mean "per-tooltip" caching ? What difference is there between links vs tooltip from inventory, except for the fact that you DON'T want to use tooltip from inventory ever ?
Hmm, I haven't looked at Heirloom items, and LIB (I'd rather use IBL or LibItemBonus) probably doesn't support them. Is that what it's about ?
It's not because something is not updated that it's dead.
AFAIK, LibItemBonus works. Otherwise, open a ticket.
The license of LIB probably needs to be stated a little bit more obviously, but the intent is that it is open source. I have a very liberal approach to whatever I contribute. You could, I don't know..., have asked about it. I find it amusing that you should say that LIB is not open source, and yet your code is nowhere to be read. I might give you a hint or two if it's publicly available somewhere.
Edit: Indeed, the license has defaulted to "All Rights reserved" sometimes ago, I did not see that. It was "license unknown" when the new wowace was created, I think. I've switched this to zlib/libpng, which is a licence that I'm most comfortable with. Feel free to rip from it whatever you want.
Performance in a parser is really not that big a deal. The only thing you need to really care about is to cache. LibItemBonus is simple in structure, precise in what it's looking for, and cache a lot of processing so that results are available really fast the second time, and that matters a lot, because mostly, you use this to get the stat values of the item the character is wearing, and that's not a large pool.
I don't mind a successor to LibItemBonus-2.0, though.