On 21 Jan 2005 at 18:39, Darcy James Argue wrote: > > I think the people who are blaming memory paging for the corruption > > have a fundamental misunderstanding of the structure of a modern > > operating system. > > Just to be clear -- I'm not "blaming memory paging for the corruption" > and I don't think anyone else here is either.
Not you, Darcy, but others have suggesting paging as a possible source of corruption, which is blatantly impossible, unless the OS X virtual memory system was improperly designed. > What I'm suggesting is that Finale stop using the same set of temp > files for all open documents -- *that* is what's allowing the > corruption to happen. Coda says this would cause a performance > degradation. However, it would also cause a marked performance > *boost* if temp files were stored in RAM, not on disk -- we know this > from the OS 9 days, where everyone who knew what they were doing set > up a RAM disk for temp files. This performance boost might well make > up for the performance hit we'd take by preserving separate temp files > for each open document. I don't know what the actual filespace usage of Finale temp files on disk because all Windows Explorer reports to me for some of them is 0- byte size (the files are still open pending writes, so nothing definitive is reported; this is often the case with temp files from any number of applications -- you can see your disk free space dropping but the temp files stay at 0 bytes). It could be that Finale uses disk space quite inefficiently for performance reasons, so that mapping the same thing into RAM could actually be an order of magnitude over what modern systems could handle. I don't know -- I'm just speculating here. I do know that the Jet database engine (used by MS Access, for instance) uses temp files that can be quite large. It depends on the type of operation. A Cartesian join will generate a very large temporary data set (since it consists of a join between two tables where the number of resulting rows is equal to multiplying the number of records in the table by each other; i.e., a Cartesian join of a table with 10 rows and a table with 4 rows will have 40 rows). Jet temp files can be 100s of megabytes. Put that in RAM and you've got a problem. So, my assumption is that Finale is solving the same kinds of problems in temp files instead of in RAM precisely because the space needed is quite huge, too large for standard RAM configurations. > RAM disks aren't a good idea in OS X, so it would be nice if Finale > offered an option to simply store them in RAM. If there was > insufficient physical RAM for this, OS X would simply swap out to > disk, but then you'd be no worse off than we were before. If it's in RAM and there's not enough memory, the virtual memory subsystem will take care of the memory swapping for you. > (Of course, they could also just fix the problem where the window > handle/ID starts to map to the wrong Enigma Doc ID, but apparently > that's easier said than done.) Storing temp files in RAM (which is really not using temp files at all, of course) would do *nothing* to fix the problem if the problem is messed up pointers. If all you're doing is changing whether the pointers point to files or pages in RAM, you're not actually addressing the fundamental problem at all. You may get a performance increase. You may not. It all depends on exactly what the temp files are being used for. -- David W. Fenton http://www.bway.net/~dfenton David Fenton Associates http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list [email protected] http://lists.shsu.edu/mailman/listinfo/finale
