in reply to Re: Speed reading (files)
in thread Speed reading (files)

Read is still faster, but the difference is very minute. Using read is still no worse than the true traditional slurp, which I find interesting.
using read function 0.614683866500854 0.604650020599365 0.616497039794922 0.640319108963013 0.603079795837402 0.605829000473022 ikegami's code 0.672801971435547 0.667882919311523 0.666944980621338 0.670393943786621 0.712579011917114 0.767023086547852

Replies are listed 'Best First'.
Re^3: Speed reading (files)
by ikegami (Patriarch) on Aug 04, 2005 at 19:58 UTC

    The advantage of "slurping" is that it works with ttys. I don't think -s does.

    Also, is read guaranteed to return the number of bytes requested (if the file is big enough)? sysread isn't.

    As an aside, wouldn't read FILE, my $data, $MAX_FILE_SIZE; be faster than using -s, especially on smaller files? I guess you have to find an acceptable $MAX_FILE_SIZE (in Config.pm, maybe???)

    By the way, I'm not suprised that read is as fast or faster than "slurping". Why wouldn't it be?

      Also, is read guaranteed to return the number of bytes requested (if the file is big enough)? sysread isn't.

      Could you clarify this for me?

      From sysread:

      sysread ... Returns the number of bytes actually read, 0 at end of file, or undef if there was an error ...

      Under what circumstances would sysread fail to return the number of bytes actually requested?


      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.

        Good question. I've heard it many times of the years, but I can't say where. Maybe it's when the handle is not a file handle. FreeBSD's man 2 read supports this theory: "The system guarantees to read the number of bytes requested if the descriptor references a normal file that has that many bytes left before the end-of-file, but in no other case."

        btw, [doc://sysread] works better than [sysread].