; slow
while (something) { var %x = thing }
; fast
var %x
while (something) %x = thing
Who knew curly braces and 'var' would slow things down so much*?
curly braces are a tad slower because mIRC has to locate the closing '}' ;P
/var is a bit slower since it's converted into one or more /set commands at a lower level. '%var =' is mapped (onto 'set %var') but this occurs a bit further down the line and the process isn't as involved. the fastest equivalent method of looping is therefore:
var %x
while (something) !set %x thing
where /!set of course tells mIRC to bypass custom aliases and immediately refer to the inbuilt /set command.
Specifically, regular expressions to get rid of non-space whitespaces, and leading, double, and trailing spaces. Turns out a $replace() followed by a 'tokenize 32 ... | %var = $1-' was significantly faster.
use "$gettok($replace( ... ), 1-, 32)" to trim those spaces
.. it prompted me to check out some other things** and try to speed-test all the things.. and then use only the fastest variants.
* by 'much' I mean a second over a loop of, say, 50000 counts. Yeah, almost not worth the botehr.
exactly. it's interesting to consider micro-optimizations since they usually reveal certain pieces of information about the language, but from a practical standpoint it's rather a waste of time.
100 $bfind()'s took a whopping 12.117s.
Now here's the thing that bugs me about that...
If I instead just fopen the file and use fseek with a wildcard search to find that same unique something in the middle, 100 runs took a blazingly fast 0.11s!
i assume you realized that those subsequent /fseeks were starting from the beginning of the line matching your previous /fseek -w call ;P /fseek -w does indeed seem to be faster than $bfind().text but only about 3-4 times so. still significant, and a rather puzzling result given you would expect the latter to involve less work internally.
oh, wait a minute.. the reason subsequent fseeks aren't going anywhere is because it fseek from the position of the pointer inclusive. If I fseek 1 char (actually, i suppose I could read a char, saves having to inc %pos 1, then it does find subsequent results. Might be worth a shot replacing my bfinds with fseeks, then.
haha yes, but be careful: that pointer position, as mentioned up there, is at the beginning of the entire line. unless you're using a wildmatch such as "stuff*", you may still locate that very same line if you only advance the current position by one byte.
the correct way to handle "*stuff*" is to grab the entire line with $fread(), loop through all occurrences of 'stuff' (with $pos(), for example) since there could be multiple, then when you're done use /fseek -n to advance the pointer to the next line in preparation for your next /fseek -w.
