|
krunch
|
krunch
|
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
|
|
|
|
Joined: Aug 2004
Posts: 7,168
Hoopy frood
|
Hoopy frood
Joined: Aug 2004
Posts: 7,168 |
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.
|
|
|
|
krunch
|
krunch
|
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
|
|
|
|
Joined: Dec 2002
Posts: 3,015
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 3,015 |
$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.
|
|
|
|
krunch
|
krunch
|
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
Last edited by krunch; 21/02/06 04:23 AM.
|
|
|
|
Joined: Aug 2004
Posts: 7,168
Hoopy frood
|
Hoopy frood
Joined: Aug 2004
Posts: 7,168 |
Looks like yet another slow down report for 6.17...there seems to have been a lot of these.
|
|
|
|
Joined: Oct 2005
Posts: 1,671
Hoopy frood
|
Hoopy frood
Joined: Oct 2005
Posts: 1,671 |
I blame the Unicode. Maybe there should be a non-unicode version available..
-genius_at_work
|
|
|
|
Joined: Jan 2003
Posts: 2,125
Hoopy frood
|
Hoopy frood
Joined: Jan 2003
Posts: 2,125 |
(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.
|
|
|
|
krunch
|
krunch
|
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
|
|
|
|
Joined: Oct 2005
Posts: 1,671
Hoopy frood
|
Hoopy frood
Joined: Oct 2005
Posts: 1,671 |
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
|
|
|
|
Joined: Dec 2002
Posts: 3,841
Hoopy frood
|
Hoopy frood
Joined: Dec 2002
Posts: 3,841 |
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.
|
|
|
|
Joined: Jan 2003
Posts: 2,125
Hoopy frood
|
Hoopy frood
Joined: Jan 2003
Posts: 2,125 |
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.
|
|
|
|
|