On 21 Jan 2005 at 20:02, Darcy James Argue wrote: > Okay, I see what you are saying now -- I assumed that OS X was > accurately reporting the size of Fin temp files, whereas Windows was > just giving you zero KB for the whole temp files folder. . . .
I'm just reporting how other database applications utilize temp files. If the amount of space needed were really so trivial, why would something so slow as disk space be used for it? > . . . But what you > say makes sense. I would like some confirmation from Coda about this, > though. Seriously, I wouldn't be surprised if the temp files were > small enough to be stored in RAM, and the whole "temp file" system was > just an inefficient holdover from Finale's earlier incarnations. (I > mean, think of all the other aspects of Finale that meet that > description!) If I'm not mistaken, Finale back in the 2.x days did not use temp files. And those were the days in which 15MBs was a lot of RAM. But maybe I just didn't notice it, or just don't remember. > >> (1) Segregate the temp files so that they are not shared between > >> multiple documents. > > > > I've never quite understood the logic of the explanation we were > > long ago given for the combined temp files, as it's an optimization > > for something I never do (I just never copy data between files, or > > maybe once every 6 months). > > I do it a little more frequently, but it's certainly not something I > do every day. And I would *much* prefer waiting a little longer when > copying between files to the current situation of taking a massive > gamble every time I want to have multiple simultaneous files open -- > which *is* something I do every day. (In fact, it astounds me that so > many people on this list never have multiple documents open > simultaneously.) I don't very often at all. The only time I tend to is when extracting parts, which is itself not something I do very often, and even then, it's not a state that I end up staying in for a long period of time. > > No, it's because you now have good disk caching, so that the temp > > files are in RAM already (in the disk cache). > > Ah. I see now. I guess that hadn't occurred to me -- probably > because Finale performance in Mac OS X is already so poor, I found it > difficult to entertain the idea that things could be any *worse*. The performance problems are no doubt optimizable. I would expect the next OS X version of Finale to be much faster. This stuff is hard. Transitioning to a completely different platform is tough work because the tricks you know either don't work or make things worse in the new environment. It's quite common for a first major version to be a performance hog, and it's a proper programming strategy to leave performance optimization to a secondary release. -- 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
