Im not sure if this is a bug but when using this code in mIRC 6.16
alias tmp {
var %ticks = $ticks
echo $findfile(f:\mp3s\,*.mp3,$r(1,$findfile(f:\mp3s\,*.mp3,0))).shortfn took $calc(($ticks - %ticks) /1000)
}
it returns
f:\mp3s\Singles\TISM-(~1.MP3 took 0.531
but when in mIRC 6.17 it
returns this
f:\mp3s\FULLCD~1\ROLLIN~1\CD2\16-TUM~1.MP3 took 17.625
thats seems to be a big time difference
The fact that you have a random factor in your code will make a difference, although how much of a difference I'm not sure. To do a proper comparison, replace that random factor with a fixed amount and the run your tests, that way you'll be getting the timings based on exactly the same information.
changing the $r(1,$findfile(f:\mp3s\,*.mp3,0)) to $r(1,8000)
give the return of
mIRC 6.16
f:\mp3s\FULLCD~1\KILLBI~1.1(O\14-''T~1.MP3 took 0.109
mIRC 6.17
f:\mp3s\FULLCD~1\VA-LUD~1\05-SHA~1.MP3 took 10.64
so there still seems to big a difference
$r(1,1800) is not a fixed value.
Change it to a real fixed value (e.g. 1, 2, 3, 3000) and then try it. Don't use $r, that gives a random number and hence a random test.
Also note that there is caching involved, even after you close mIRC. The first run of the alias will take longer than subsequent ones, even in seperate mIRC sessions.
how to clear the cache?
running the test
$findfile(f:\mp3s\,*.mp3,2300).shortfn
mIRC 6.16
f:\mp3s\FULLCD~1\FOOFIG~1\08-LON~1.MP3 took 0.078
mIRC 6.17
:\mp3s\FULLCD~1\FOOFIG~1\08-LON~1.MP3 took 1.547
thats with out clearing the cache, but ran in that order, .16 first then .17
Looks like yet another slow down report for 6.17...there seems to have been a lot of these.
I blame the Unicode. Maybe there should be a non-unicode version available..
-genius_at_work
(general reply) you people are getting a bit ahead of yourselves. As Collective said, you'd have to do a test with a fixed number and repeat it a fair number of times, since any subsequent $findfile()'s are much faster due to caching (Windows, not mirc). I did some testing too and found absolutely no performance difference in $findfile() between 6.16 and 6.17.
As for Unicode having to do anythign with the reported slow-downs (the real ones, like /timers or, for some people, window switching and/or text display), I don't think anybody has (or can supply) any evidence that support this.
I hope that is the case that there is now performance difference,
but I cant see why I'm getthing these differences
im running that test code on 6.16 first and then 6.17 so if anything it should be faster but its still slower
Try restarting your computer, and then running the hardcoded (not random) version of the code on 6.16. Then restart your computer again and run the same code on 6.17. That way there should be no advantages given to either mIRC.
-genius_at_work
This is due to the extra processing needed for the new ; semi-colon feature in $findfile(). I'll see if I can change it so that it works as fast as before if the ; semi-colon is not used.
You're absolutely right, I stand corrected. The difference is barely noticeable with small N's (I tried with N up to 500 in my initial tests) but since I didn't find any difference then, I didn't bother with bigger numbers. This was a mistake: testing on a big hard drive with 15,000 files, N being 0, I did notice a big performance difference.