On Friday, December 30, 2005 @ 3:45, Carlos Robinson wrote:
The Thursday 2005-12-29 at 19:30 -0900, Greg Wallace wrote:
Right. Assuming it works like 'doze, the first load causes a memory to memory copy to create a cached version. This should happen very quickly. The majority of the time spent on the initial load is getting the binary(s) off of the disk, which would happen even if there were no caching done.
Correct; but not only binaries, but everything.
But just the read only portion is cached, right? The working copy (temporary storage holding values you input but not saved) is modified by what you do while you're modifying a data file but that doesn't change what's cached. The cached copy is just a blank slate, suitable for a pure memory to memory copy if you exit the app and then call it back up. I wouldn't think that any special/seldom used forms would be loaded by default either, but would only be loaded if you actually went to one of those during your edit session. Probably just the initial form that you see when you start the app (and maybe a few commonly used ones) is loaded when you call up the app the first time.
By the way, I forgot to mention a thing that slows a bit disk access in Linux: the filesystem stores in disk the timestamp when any file is read, ie, a write operation for every an each read. The operation is cached, of course, but it does slow things.
You can disable this with the option "noatime" in fstab. I have all my partitions that way for over a year or two and I haven't seen side effects yet.