punkish has asked for the wisdom of the Perl Monks concerning the following question:

With the belief that "cache is always better than a check" I have observed a curious but happy oddity on my unattractive but capable Dell laptop with AS Perl 5.8.8. I have an external USB disk connected with tens of thousands of DBF files on it. I wrote a small script that rips through all those files and prints out (to a text file) the structure of those dbfs. This is what I noticed --

When I first ran the script, the hard disk light flickered away, and I could here it whirring. The script ended, and I got my result. Then I ran the script again (accidentally, I must say... I was hitting the up arrow to get another command from history, but accidentally got the script and ran it). This time the script ran without any hard disk activity. Curious, I ran it again... same... no activity, but a new file got created. What is going on? Has my Perl decided there is no need to make a trip to the hard disk? Fine by me, but I want predictable servants, not those with a mind of their own.

--

when small people start casting long shadows, it is time to go to bed

Replies are listed 'Best First'.
Re: does perl cache between invocations?
by perrin (Chancellor) on Jul 15, 2006 at 19:52 UTC
    Perl doesn't cache anything. That's why things like mod_perl and PPerl are useful. What you're seeing is your OS caching files, which is a standard feature of any modern filesystem.
      
      > What you're seeing is your OS caching files, 
      > which is a standard feature of any modern filesystem.
      

      Interesting... I wonder what this filesystem is looking at to determine that my Perl script doesn't need another roundtrip to the hard disk. After all, afaik, my script is compiled to some kind of bytecode... I wonder if the OS is looking at the signature of the bytecode, coupling it with the request for files, and saying to itself, "Aha! this fellow just asked me for the same file... let me hand it to him from the cache..."

      --

      when small people start casting long shadows, it is time to go to bed
        It's much lower level than that. The OS knows whether or not anything has tried to write to that part of the filesystem, so if nothing has, it knows its cache of the file is still good. Perl is still compiling every time -- the opcode tree of your program is not stored anywhere between calls to it -- but the actual file access that is sped up.
        It's saying to itself, "Aha! this fellow just asked me for the same file... let me hand it to him from the cache..."


        holli, /regexed monk/
Re: does perl cache between invocations?
by jhourcle (Prior) on Jul 15, 2006 at 19:26 UTC

    Perl on its own doesn't cache that I know of (assuming you didn't add specific cacing routines into the program, or use an alternate perl context)-- but some disk drives will. Sometimes it's the individual disk drive, sometimes it's an optimization of the OS. (laptops are much more likely to use disk caching, as it can improve battery life)

    Try changing a couple of the files, re-running the program, and making sure that the changes were picked up -- if they were, I wouldn't worry about it.

Re: does perl cache between invocations?
by shenme (Priest) on Jul 15, 2006 at 22:46 UTC
    Looking at my WinXP "task manager" display, I see that "System Cache" is currently 465MB. Now the OS uses that to hold many different things, but also recently read disk data. The question becomes not how many files, but how much space they total together.

    If I wanted to read the same 200MB of file data again and again, I (likely) would not see the disk light flash because all the data would fit and still be present in the cache memory. If I needed to repeatedly process 500MB of file data, I likely would find other things to do while the disk light flashed for many minutes, _each_ time, because all the data could not fit in cache and _must_ be re-read each time.