Forums Scripts & Popups Get mIRC to watch text file and dump text live

hixxy said nothing to detract from your explanation of file handling, you managed to do that all on your own by swaggering into the thread with your baseless assumptions. have you considered that mIRC is not a low level language and that it can often be rather futile to try and map a block of mIRC script onto a set of low level operations? this is why we conduct tests such as benchmarking in addition to merely conceptualizing since the latter method of analysis can fall short unexpectedly. hixxy's tests have shown his method to perform faster in mIRC in the general case. if you don't believe him then by all means try to disprove his claim, but don't go throwing around nonsense claims such as 'Most users who have post counts into the 1000s make it impossible for me to explain file handling'.

True cheers



This hits the nail on the head really.

In theory the file handling method should be faster than using /filter and $lines(), because mIRC has less data to read from the file using the former method.. but when you consider the overhead of mIRC having to interpret a few extra lines of code, including a while loop, then it tends to be a lot faster to use /filter, which is just a single command that calls a lot of low level (fast) file handling routines.

A. File handles are low level operations.

B. Benchmarks don't reflect real world performance. This is a perfect example. We're monitoring a file that is constantly changing. We don't know the size of the file. Or it's contents. Hixxy's example will be faster the first time, but on large files will start seriously slowing down each subsequently called. Even on the largest files, GBs in size, performance will be consistent after the first call. Taking about 0-1 ms to complete. Test this yourself.

C. Shutup and just benchmark them yourself IN REAL WORLD conditions... then get back here... I refuse to do it for you because you won't believe it. You'll just do what Hixxy did and claim I was using /fseek unfairly*. THERE IS NO WAY TO UNFAIRLY USE AN OPERATION. Please PROVE ME WRONG!

* From this thread

P.S. BTW move this conversation to THAT thread please.

When reading a 5000-line file from the beginning on 6.35 your /filter method is considerably faster than the /fseek method, but it seems to be slightly slower on 7.08 (ouch). In both versions /fseek is much faster at reaching the last position in the file for subsequent calls, which is important when polling frequently.

(general reply)

relating this to the issue at hand, there are 2 obvious possibilities: either the file has changed or it hasn't. if the file has not changed, then both approaches (/filter and file handling) perform wasteful operations when a simple $file().mtime check is sufficient. this is as important a consideration as the one we're currently discussing since the file is likely to be polled often and (presumably, for a pager script) the majority of those polls will result in no indication of change.

then the 2nd and more thought provoking consideration is, given the file has changed, how best to return the changes. admittedly, i didn't examine the codes here - i wholeheartedly agree that maintaining a byte position and seeking to it is more efficient than calling a function that, even implicitly, has to examine each character to see if it constitutes a line break, count those, etc.; that is self evident.

however, the gist of my reply to you, MeStinkBAD, is still valid because you are speaking in too general terms. the question of whether /filter or file handling should be used in the general case is silly. they are quite different features and both have their own particular set of suitable applications. in this particular case, i would advocate a healthy mixture of the two. initially, we should use /filter (or the more suitable /loadbuf) to load the file into the window if this is the first call to the alias (lastfpos is unset) especially if the file is sizable. then, as the file's size increases, maintaining a byte position to seek to in the event of a change is indeed the way to go.