//echo -a $hget(orion,$hfind(orion,$str(* $+ $chr(9),4) $+ %string $+ *,1,w).data)
I would change that to
//echo -a $hget(orion,$hfind(orion,$str(* $+ $chr(9),4) $+ %string $+ $chr(9) $+ *,1,w).data)
To ensure no accidental part matches such as %string = "fred" making *<tab>*<tab>*<tab>*<tab>fred<tab>* which wont mistakenly match to say fredrick
One thing about the 1.5s was it on every match not just ,1, ?
Im also unsure on the order of results of using hfind (i have never checked them) do they come in the order they would appear in a hsave file? I would think it likely is.
Since you have the sample data, try changing it to search for something in say ther 14th token and see if there is a increased delay, i have a feeling there well be.
Side Note: I had this same type of problem with /FILTER i was filtering from different tokens in it in like token number 18 to 22, and the delay was horrible, I finally added a extra token at token 18 that was a unquie value (cant remeber what it was lets say it was ¥) so then i could filter on *¥~*~*~*~*~ $+ matchtext $+ ~* (for token match on 22 now token 23)
aka i allow it to jump all the starter tokens and align to where its ment to be using a unique marker on each line to aline with.
(this of course means a adjustment of the data, which isnt always possable)
How often is the code triggered as even 1.5s is pretty high pause rate for mirc if your doing it alot, or your looping.
A /hsave -n followed by a /filter -n on the file giving you a result set with the first word as a backrefrence number to $hget(table,N).data might be faster (if theres a lot of matches to find)
^-- that idea is the same princible as the sorting hashtable values thing with using /filter -n (hope im making my self clear enough here)
