On 19 Jan 2005 at 12:16, [EMAIL PROTECTED] wrote:

[]

> I'm now suspecting that when one has many files open at the same time,
> (or in my case, when many people are working off one server) and auto
> saves are happening, along with regular saves and the whole temp file
> thing that Finale requires a ton of RAM, perhaps more so than other
> apps that don't have some of these features or ways of dealing with
> temp files (sorry if this seems obvious)

You should be able to figure out how much RAM Finale is using by 
using your OS's version of TOP (on Windows you can use the Task 
Manager for that). You should check RAM using before loading Finale, 
RAM usage after loading Finale with no files, then check RAM usage as 
you open more and more files, then close all files and check RAM 
usage.

My bet is that you'll see VERY LITTLE DIFFERENCE -- that's the whole 
point of temp files, that all the temporary stuff is written out to 
disk and only the current workset is kept in memory. Yes, as the 
number of files open increases the size of the pointer table that 
connects files open to temp files will increase, but that's, memory-
wise, a very small thing.

> The way that OS X deals with memory or lack thereof is interesting.
> When the OS is out of RAM it starts to copying data from RAM to the
> Hard disk (this is called paging) The file that the OS copies to on
> the hard disk (I should be more specific...boot disk) is called
> a...don't laugh...a swap file.  This process is the virtual memory
> part of OS X.

Er, um, all current versions of Windows have been doing that since, 
oh, 1994 (NT 3.1 came out in 1991, and, naturally, had pageable 
virtual memory; 1994 is the date of the release of Windows for 
Workgroups; even previous versions of Win3.1x had pageable swap 
files, but the virtual memory system as a whole was not nearly as 
robust).

Every modern operating system has always supported virtual memory 
paging. The Mac OS was the last "modern" OS to get it, and because it 
was bolted onto an architecture that wasn't designed for it, it often 
caused problems. OS X being based on a UNIX variant was designed from 
the ground up with that kind of thing in mind.

> So, I'm wondering if there is some sort of confusion somewhere with
> what is getting copied to/from what when the system resources are
> taxed thus creating the Overwrite Bug. . . .

I very strongly doubt that this has anything to do with system 
resources and has everything to do with the very odd Finale temp file 
architecture that mixes content from multiple files within a single 
temp file. The only thing required to then produce the bug (i.e., 
content from the wrong file) is for the pointer table that maps open 
files to temp files to get messed up.

[]

> This may explain why Finale is faster after a restart and why it seems
> that temp files are becoming bloated/corrupted after a long Finale
> session.  It may not be the files themselves but rather that more
> paging has occured over a long session as OS X tries to juggle memory
> resources.

It's probably not paging. It's just that writing to temp is orders of 
magnitude slower than writing to RAM, especially if you're having to 
write certain things in order. That is, if the file needs to be 
maintained with blocks in certain order, e.g., block A, block B and 
block C, and say that block A outgrows the allocated file space. Then 
to write block A, at the very least, at least some sectors of block B 
(and possibly all of block B and some or all of block C) will need to 
be rewritten, as well. 

Now, that scenario has probably been planned for, but the amount of 
churning people are describing with temp files leads me to believe 
that somewhere in the temp file handling, there's some process that 
is subject to this kind of churn effect.

But I strongly doubt the whole set of problems have anything to do 
with RAM or virtual memory, both of which are completely transparent 
to Finale and should never cause any kinds of problems for the 
application -- if it's a problem, the app just grinds to a halt -- it 
would never lead to the corruption of structures internal to the 
program (the virtual memory subsystem knows nothing about the content 
of the memory pages being swapped).

-- 
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

Reply via email to