zaccone@jasper.bucknell.edu (zaccone - 1393) (05/31/91)
I am running System 7 and DiskExpress II 2.07. I usually let DiskExpress do its job with my machine unattended because I find the disk chattering annoying. Since switching to System 7, I noticed that the speed of the optimization depends on which application is currently active (even though nothing is going on). For example, if the Finder is active the optimization takes at least twice as long as with System 6.0.7 (I haven't measured it exactly). However, if a MultiFinder hostile program such as StuffIt Deluxe is active, the optimization runs much faster. I've noticed this effect with my screen saver too. It runs slower when the Finder is active. In fact, this is how I figured out how to speed up my optimizations. To select the program that I should leave active, I tried out several and watched how the screen saver performed. Has anyone else had similar experiences? Rick Zaccone -- zaccone@bucknell.edu
dplatt@ntg.com (Dave Platt) (06/03/91)
In article <ZACCONE.91May31101235@jasper.bucknell.edu> zaccone@jasper.bucknell.edu (zaccone - 1393) writes: >For example, if the Finder is active the optimization takes at least >twice as long as with System 6.0.7 (I haven't measured it exactly). >However, if a MultiFinder hostile program such as StuffIt Deluxe is >active, the optimization runs much faster. > >I've noticed this effect with my screen saver too. It runs slower >when the Finder is active. I've seen similar things with my screen-saver (Moire), and with Dan Tappan's "macdump" network-backup RDEV. If the Finder is the only thing running, network backups take about twice as long as if something else is open. I noticed this same effect under System 6.0.5 and 6.0.7, when MultiFinder was active. If I ran in a single-Finder environment, backups would run at full speed. My inference is that these utilities are patching themeselves into SystemTask or GetNextEvent or some such task, which is called directly (and very frequently) under 6.0.whatever in the single-process environment. In 6.0.whatever under MultiFinder, or under 7.0, these traps are called indirectly, via WaitNextEvent. If the Finder is the only process running, and if it's idle, it apparently calls WaitNextEvent with a delay-time of somewhere on the order of a second or so. This limits the trap-patch tasks to only one time-slice or so per second, and the machine spends a lot of its sitting idle. This is one situation in which the background utility would be better off if it were implemented as a faceless application (i.e. like Backgrounder) rather than as a trap patch. When active, it would be able to yield time-slices via GetNextEvent rather than by exiting to the original trap-handler, and thus it would become eligible for first-class timeslice treatment under MultiFinder/ProcessManager. The workaround I've settled on, when I run "macdump" backups on our network, is to simply ask everyone to open their Alarm Clock desk accessory. With this DA running, the trap-patch utilities get time-slices at full speed. -- Dave Platt VOICE: (415) 813-8917 Domain: dplatt@ntg.com UUCP: ...apple!ntg!dplatt USNAIL: New Technologies Group Inc. 2468 Embarcardero Way, Palo Alto CA 94303