Originally Posted By: RRX
Read alone! Never add! Never replace! Never delete! That's true!

Okay, convince me. Show me benchmark results on your most common commands using @windows versus files... I mean, surely you seem to know beyond the shadow of a doubt how much slower it is so you must have done benchmarks, right?

You know what, don't convince me, I'll just do it myself. I'll test mIRC's sorting algorithm, which is probably the slowest part of /filter:

alias bench {
  var %x = 1, %ticks = $ticks
  while (%x <= 5) { $1- | inc %x }
  echo -a Command completed in (avg over 5 runs) $calc(($ticks - %ticks) / 5) ticks: $1-

alias lensort { return $iif($len($1) > $len($2), 1, $iif($len($1) < $len($2), -1, 0)) }


Note: @tmp1 was loaded with the same logfile before running the test, @tmp2 was empty. #somechannel was changed to protect the innocent, but the file is 247.58KB.. a pretty large sample size for a sorting operation even given only 5 trial runs.

Command completed in (avg over 5 runs) 3110.6 ticks: filter -ffa logs\#somechannel.log logs\#somechannel.log2 lensort
Command completed in (avg over 5 runs) 3085.6 ticks: filter -wwa @tmp1 @tmp2 lensort

So you're right. Window operations are faster!!!!!!

edit: The excitement was sarcasm, by the way.

edit2: Other uses of filter give similar results. I get 14.19 ticks using window-to-window filtering for a simple wildcard match of *mirc* versus 17.16 ticks using files (avg over 100 runs). As you can see, smaller operations take the biggest hit because the slowdown is due to the overhead in opening the files, not accessing them. At the same time, however, the cost from a smaller operation is equally negligible because the operation is negligible in itself. A difference of 3 ticks is not differentiable, even though it's technically 20% slower.

Last edited by argv0; 01/08/08 01:30 AM.

- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"