The first is of a magnitude faster than the second. Hash table lookups ARE SLOW and are NOT CONSTANT TIME. The larger the table, the more time it takes to find it.
Could you please elaborate? People normally use hashtables for their constant lookup times, and we typically think of them as being more effective as the data set grows larger (compared to a sequential data structure). This seems counter-intuitive to me, but perhaps Lua does things differently.
You could get the value of time() when a button is pushed, then in OnUpdate() check the difference between the current time() and the original value. I believe the OnUpdate call also passed in the amount of time elapsed since the last update as described here http://www.wowwiki.com/Using_OnUpdate_correctly. Or you could use AceTimer, I suppose.
Reading the tooltip is risky because looting object is not instantaneous, meaning the tooltip might have changed at the time the loot window is opened. What you should do instead is watch for a successful spell cast and register for the loot window opened event only if the spell cast was one you were interested in. For chest, the English spell name is "Opening".
I have noticed that AceComm-3.0 no longer prevents loopback when sending a a comm message to a broad distribution such as "PARTY" or "RAID". If you are the originator, you get your own messages, which in some cases can prove problematic. I suppose this is caused by the underlying Blizzard API function SendAddOnMessage which sends to everyone in the distribution, including yourself.
Of course it is possible to work around it in my addons themselves by checking if sender ~= UnitName("player") but I was curious if it was an intended design choice in AceComm-3.0 or an oversight. In the latter case, is there any plan to prevent loopbacks? Or is it already there and I'm missing something? I know AceComm-2.0 used to prevent loopbacks, which prompted my question.