Re^7: Working with fixed length files

I re-read BrowserUk's post, and I still don't see that line. And yes, I copied it exactly.

Look at his benchmark code, you know, the node with the numbers :)

Adding that line to his code is unfair, as that will skip half of the data. Fair would be to use \122, but that doesn't change much:

Ok, right, he had \123, the difference is smaller

5.008009
      Rate  ike  buk
ike 34.7/s   -- -17%
buk 41.6/s  20%   --

v5.12.2
      Rate  ike  buk
ike 32.9/s   -- -16%
buk 39.4/s  20%   --

v5.14.0
      Rate buk ike
buk 45.5/s  -- -1%
ike 45.9/s  1%  --
[download]

Maybe i'll run buk's benchmark now

Comment on Re^7: Working with fixed length files Download Code

Replies are listed 'Best First'.
Re^8: Working with fixed length files by Tux (Canon) on Apr 28, 2011 at 10:02 UTC
Right. I can explain that! ikegami reads in two lines in one go and unpacks both lines with one single `unpack`, which is why he uses `\(2 * 122)`. That makes his test code almost twice as fast as the code that BrowserUk translated it to, which reads the two lines in two separate read/unpack sequences. The difference between `\122` and `\123` is most likely to blame on Windows line endings. That is why ikegami used x2's and BrowserUk uses x3's. Interesting thread though :) Enjoy, Have FUN! H.Merijn	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^8: Working with fixed length files
by Tux (Canon) on Apr 28, 2011 at 10:02 UTC

Right. I can explain that!

ikegami reads in two lines in one go and unpacks both lines with one single unpack, which is why he uses \(2 * 122). That makes his test code almost twice as fast as the code that BrowserUk translated it to, which reads the two lines in two separate read/unpack sequences.

The difference between \122 and \123 is most likely to blame on Windows line endings. That is why ikegami used x2's and BrowserUk uses x3's.

Interesting thread though :)

Enjoy, Have FUN! H.Merijn

[reply]
[d/l]
[select]