You seem to be right: getting the file size is an expensive operation on windows. (BTW, this is with a different file, shimgvw.dll, having about the same size as your words. Also, there's a little bit of cheating here -- I found the best blocksize for sysreadby by testing with every power-of-two from 1 to 512k. Also, numbers with open/read vs. sysopen/sysread were about the same, so only the sysfoo number are here.) My final numbers:

Benchmark: running join, slurp, sysread_wholefile, sysreadby32k, while
+, each for at least 5 CPU seconds...
      join:  6 wallclock secs ( 2.98 usr +  2.27 sys = .26 CPU) @ 5320
+.53/s (n=27970)
     slurp:  5 wallclock secs ( 2.55 usr +  2.76 sys = .32 CPU) @ 6339
+.04/s (n=33711)
sysread_wholefile:  6 wallclock secs ( 0.39 usr +  4.89 sys =  5.28 CP
+U) @ 360.93/s (n=1905)
sysreadby32k:  5 wallclock secs ( 2.35 usr +  2.97 sys = 5.33 CPU) @ 6
+879.48/s (n=36647)
     while:  6 wallclock secs ( 3.07 usr +  2.19 sys =  .26 CPU) @ 531
+9.51/s (n=27970)
                    Rate sysread_wholefile   while     join   slurp sy
+sreadby32k
sysread_wholefile  361/s                --    -93%     -93%    -94%   
+      -95%
while             5320/s             1374%      --      -0%    -16%   
+      -23%
join              5321/s             1374%      0%       --    -16%   
+      -23%
slurp             6339/s             1656%     19%      19%      --   
+       -8%
sysreadby32k      6879/s             1806%     29%      29%      9%   
+        --
[download]