Seeking doesn't change the benchmark, here's code and a random sampling:
alias benchfwrite { .fopen x test.txt | .fseek x $file(test.txt).size | .fwrite -n x Hello world | .fclose x }
alias benchwrite { write test.txt Hello world }
; Results
Command completed in 218 ticks (0.218 avg over 1000 runs): 1000 benchwrite
Command completed in 219 ticks (0.219 avg over 1000 runs): 1000 benchfwrite
Command completed in 218 ticks (0.218 avg over 1000 runs): 1000 benchfwrite
Command completed in 234 ticks (0.234 avg over 1000 runs): 1000 benchfwrite
Command completed in 249 ticks (0.249 avg over 1000 runs): 1000 benchfwrite
Command completed in 218 ticks (0.218 avg over 1000 runs): 1000 benchwrite
Command completed in 187 ticks (0.187 avg over 1000 runs): 1000 benchwrite
Command completed in 188 ticks (0.188 avg over 1000 runs): 1000 benchwrite
Command completed in 172 ticks (0.172 avg over 1000 runs): 1000 benchwrite
Command completed in 172 ticks (0.172 avg over 1000 runs): 1000 benchwrite
Command completed in 187 ticks (0.187 avg over 1000 runs): 1000 benchwrite
Command completed in 250 ticks (0.25 avg over 1000 runs): 1000 benchfwrite
Command completed in 203 ticks (0.203 avg over 1000 runs): 1000 benchfwrite
Command completed in 203 ticks (0.203 avg over 1000 runs): 1000 benchfwrite
Command completed in 187 ticks (0.187 avg over 1000 runs): 1000 benchfwrite
Command completed in 234 ticks (0.234 avg over 1000 runs): 1000 benchfwriteAll seeking does is set an integer on an internal data structure, it would seem extremely fishy to me if the seek alone could be responsible for a difference of 100% slowdown... especially when the only difference is the overhead of the extra script parsing (mIRC is already fseeking internally when using /write, so it's not fseek() itself that is the slow bit). My guess is either you have this problem without seeking (you should take out and re-test the benchmark to confirm you have the same initial values) or your benchmark is broken.
