Of course your first example is completely invalid because it has nothing to do with /filter. My claim was /filter -ww was as fast as (or only slightly faster than) /filter -ff/-wf/-fw, not that many $read's would be as fast as many memory accesses. That is a completely different function with completely different behaviour.
My answer was equally related to your 'claim' as your 'claim' was related to mine.
I say I want A and B and you pick out B and ignore A.
If you would work in a MacDonalds, and they ask you a burger with cheese, are you gonna give the burger alone?
The good thing about your example is that I can still do it with /filter using the -k switch to /write in a callback to some aux file and then merge it back after. I'll leave it as an excercise to you, but I guarantee it's not substantially slower than an $fline loop.
$fline() has nothing to do with the looping.
It was 1000 times a $fline() search for the same line.
The loop was there to get a benchmark reading with a higher resolution.
You should better exercise yourself in reading what people want.
The
other good thing about your example though, is that even without /filter, there is still a faster way to do it.. it's called
hash tables, which is mIRC's "storage method similar to custom windows" that you so incorrectly claim it lacks. Quickly converting the script to a hash table script,
alias yay { echo -ag Hash: $yayF @window: $yay@ }
alias yayF {
var %i = 1 | while (%i < 1001) { hadd -m yay %i a r g %i v 0 | inc %i }
var %t = $ticks, %i = 1
while (%i < 1001) {
var %rec = $hget(yay, $hfind(yay,& & & 500 & &,1,w).data)
hadd yay 500 $puttok(%rec,500,4,32)
inc %i
}
hfree yay
return $calc($ticks - %t)
}
alias yay@ {
var %i = 1 | window -h @yay | while (%i < 1001) { aline @yay a r g %i v 0 | inc %i }
var %t = $ticks, %i = 1
while (%i < 1001) {
var %rec = $fline(@yay,& & & 500 & &,1).text
rline @yay 500 $puttok(%rec,500,4,32)
inc %i
}
window -c @yay
return $calc($ticks - %t)
}
you find that:
Hash: 94 @window: 328
So much for faster,
again.
So much for keeping its order.
It was brought up earlier in this topic.
Someone already mentioned this drawback.
I confirmed it as relevant.
Are you a politician or so?
You seem to exhibit the same 'features'.
A magnifying glass that makes you miss the bigger picture and blind for the obvious.
Btw, the results here gave Hash: 220 @window: 480
Conclusion? Use the right tool for the right job. It really is that simple.[/code]
Conclusion?
You ignore selectively the requirements I gave.
First you changed the case to usage of /filter alone.
Here you limited the case to not keep order.
What next?
[quote=argv0]
edit: PS. I won't even bother deciphering your second example, but your initial statement is also wrong there. /filter can deal with strings like "*!*@*blah".. use the -g switch to make the matchtext a regular expression and then write it as: "\*!\*@\*blah". From what I understand, it makes your entire second alias completely obsolete.
About all mIRC's search commands support regex.
Glad you assumed I didn't know that.
Glad you didn't bother to think one step further.
Glad you didn't bother to read the url to the other topic abit, instead of wildly chopping around with an axe.
You might have had an idea why I didn't see regex as an option.
But that's a notdone eh?
Baffling around is so much easier - even more - it looks like it's your goal.
