[comp.sys.mac] Slow DeskTop-Updating with Finder-6.0 PROBLEM??

kraut@ut-ngp.UUCP (Werner Uhrig) (11/09/87)

When you copy files on the desktop (by dragging or ^D) under the new Finder-6.0
a status window displays the progress of the activity, first showing the
progress of the file-copying (with a "progress-bar" indicater, for lack of a
better term), then displaying the message "Updating DeskTop".

Practically since day one, I have noticed that copying seems to have gotten a
lot slower, especially the time spent in "Updating DeskTop" can seem endless.
in particular, I have timed the copying of a 2k-file to take 2 seconds, and the
"updating the desktop" 20+ seconds, repeatedly.  I've seen the discrepancy of
a factor of 5 to 10 between the time spent in actual copying and the Desktop
Updating pretty consistently on both my hard disks (20 and 80 Meg), neither of
which are corrupted or fragmented.  Both performed a lot better (faster) under
Finder-5.5 with a lot more files, more fragemented and with bigger DeskTop.

Friends have reported the same observation, so something changed for the
worse and I wonder if others can confirm it and if someone from Apple could
comment.  And, no, it is not a subjective reaction to the fact the now there
is a window indicating how much time is spent in updating the DeskTop;  it
really takes a lot longer then pre-6.0 !!!

PS: the Finder-6.0 comes configured to use 160k, by default, and I wonder if
	increasing that might help in some circumstances.  I really would
	like to see some info on what partition-size should be used for
	different applications under MultiFinder;  I am under the impression
	that under Switcher-5.1 many applications seemed to prefer a different
	size than what is now indigcated when doing a Get-Info on applications.

-- 
kraut@ngp.utexas.edu

lsr@apple.UUCP (Larry Rosenstein) (11/11/87)

In article <6769@ut-ngp.UUCP> kraut@ut-ngp.UUCP (Werner Uhrig) writes:
>PS: the Finder-6.0 comes configured to use 160k, by default, and I wonder if
>	increasing that might help in some circumstances.  

I don't think so.  Finder 6.0 uses the Multifinder temporary memory
allocation services, which is why it can run effectively in 160K of memory.
These Multifinder calls allow an application to temporarily allocate memory,
which hasn't been assigned to any other application.

For example, if only the Finder is running on a 1Mb machine, there is more
than 512K of RAM that is unused.  An application can ask Multifinder to
allocate a handle for it out of this memory.  

-- 
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.com

lsr@apple.UUCP (Larry Rosenstein) (11/19/87)

In article <6698@apple.UUCP> lsr@apple.UUCP (Larry Rosenstein) writes:
>In article <6769@ut-ngp.UUCP> kraut@ut-ngp.UUCP (Werner Uhrig) writes:
>>PS: the Finder-6.0 comes configured to use 160k, by default, and I wonder if
>>	increasing that might help in some circumstances.  
>
>I don't think so.  Finder 6.0 uses the Multifinder temporary memory

I have to retract this statement.  As some other people pointed out, there
are things which require memory in the Finder's heap:

* Saving bits under menus..  If you have a color screen this can take a lot of
space; if the system can't get the space it will generate an updateevent
which will slow things down.

* Mounting volumes.  The Finder has to read the desktop information into its
own heap.

* Disk copying.  Although the Finder uses spare memory to do the copy, it
needs to update the desktop file using the Resource Manager, and this
requires space in the Finder's heap.

So if you do a lot of large volume copying, or use several disks at once
(eg, file servers), it may make sense to increase the Finder's memory
allocation.

Sorry for the confusion.

-- 
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc, mtxinu, dual}!apple!lsr
CSNET: lsr@Apple.com