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.
Yeah, I read the reasons in the advanced scripting document. I guess coming from a background in scripting languages that are at least pre-parsed once to deal with exactly these sort of things, it surprised me that every single loop would have to re-do all the world.
Of course that also opens up interesting tricks like using
!goto %variable... not sure yet if that's a good thing, but as long as %variable is one in a pre-determined set, I guess it can be faster.
use "$gettok($replace( ... ), 1-, 32)" to trim those spaces
Nope - well, not always anyway. I'd say it definitely looks better.
On smaller runs (if you can call them small):
numtests: 59772.86 mult: 5.977286
1-> 4787 (gettok)
2-> 4516 (tokenize)
2-> 4517 (tokenize)
1-> 4867 (gettok)
On longer runs (definitely long):
numtests: 383043.925 mult: 15.321757
1-> 28621 (gettok)
2-> 30824 (tokenize)
2-> 30324 (tokenize)
1-> 28060 (gettok)
Numbers are in milliseconds. Ran both tests a couple of times, they were both consistent in this behavior. Weird, huh?
( I run test 1 and 2, then 2 and 1, in case either of the tests does something strange that affects the next test. )
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.
Yeah. The thing is, you can't really tell whether they're micro-optimizations until you run them against an actual use case.
While the difference between 'var %var =' and '%var =' is almost negligible, if I had any reason to need to do them a few hundred thousand times, I'd happily take the savings.
In addition, once you've identified them, there's little reason
not to make use of them (short of the ones with caveats).
i assume you realized that those subsequent /fseeks were starting from the beginning of the line matching your previous /fseek -w call ;P
Yeah, I had actually added an
fseek fname 0 to make absolutely sure it would search from the beginning, just as the $bfind did. It was still faster.
/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.
Exactly. I'll take the 3-4, if I can work that into the script and not lose them again on a bunch of logic juggling between fseek and $fopen().pos to find/get the positions I want, and $bvar to actually get the information between those two positions.
3-4 might not seem like very much, but a delay of 12 seconds parsing a page versus a delay of 3-4 seconds.. world of difference in observed behavior. A webpage that loads in 3-4 seconds is acceptable, a webpage that takes 10+, people will quickly begin to wonder if something's wrong
Definitely curious as to why $bfind would be relatively 'slow'. Then again:
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.
Oi vey - pointer at the beginning of the line... that's right.
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.
More things to try, then - although if I'm doing a per-line thing anyway, the first thing I would try is the regex route.
