info-mac@utcsrgv.UUCP (info-mac) (05/31/84)
Date: Fri, 25 May 84 18:02:10 pdt
From: uw-beaver!hamachi%ucbkim@Berkeley (Gordon Hamachi)
To: info-mac@sumex-aim.ARPA
Subject: Slow and Impossible
The finder has problems coping with even moderate numbers of
documents. I discovered this by:
Cold boot from the system disk (stock, unmodified, Apple-supplied)
Eject
Insert a completely blank disk called ``blank 9''
Create lots of empty folders, named aa, ab, ac, az, ba, bb, etc.
The finder runs out of RAM memory when trying to cope with heavily
populated disks. After 55 empty folders, the following messages occur:
Please insert the system disk
There is not enough memory to duplicate the selected item
Please insert the disk blank9
Please insert the system disk
There is not enough memeory to remember this disk.
Its image will disappear from the desktop.
[blank9] goes away.
This is specifically NOT an out-of-disk-space problem: there is still well
over 300 K of disk space available when the problem happens.
I have run into the same problem with as few as 32 empty file folders.
On the other hand, I was once able to generate a disk with over 100 files,
but it took over 34 minutes to ``Clean up'' the icons.
Am I doing something wrong? Is this problem fixed in newer releases?
Is this a toy operating system?info-mac@utcsrgv.UUCP (info-mac) (06/02/84)
Date: 31 May 84 16:37:17 PDT From: uw-beaver!wert.pa@XEROX.ARPA Subject: Re: Slow and Impossible In-Reply-To: <8405312309.AA13556@ucbkim.ARPA> To: hamachi%ucbkim@UCB-VAX.ARPA (Gordon Hamachi) Cc: wert.pa@XEROX.ARPA, info-mac@SUMEX-AIM.ARPA It seems likely that the Macintosh design team did NOT overlooked this problem. They were probably forced to rushed the 1.0 finder out the door before it was ready. Is the problem fixed in later a version? This problem does not go away with the 1.1g finder. I think this is a bad design decision (it should start tossing out folder info as the system heap gets full). Having 512k of memory will certainly help the out of memory problem, but not the slowness problem. As far as sights being short, consider another problem: There is no way to partition file names into managable groups, i.e., no directories. Folders clean up your desktop, but not the disk. This is not that much of a problem for the small floppies, but consider how you will end up naming the hundreds or thousands of files on a 10 MB winchester? Are you going to want to read all their names and info into memory too? scott
info-mac@utcsrgv.UUCP (info-mac) (06/02/84)
Date: Thu, 31 May 84 16:09:18 pdt
From: uw-beaver!hamachi%ucbkim@Berkeley (Gordon Hamachi)
To: wert.pa@Xerox.ARPA
Subject: Re: Slow and Impossible
Cc: info-mac@SUMEX-AIM.ARPA
From: wert.pa@XEROX.ARPA
Subject: Re: Slow and Impossible
Cc: info-mac@SUMEX-AIM.ARPA
What you said sounds right on the mark. If Apple didn't anticipate
more than 50 files per disk, don't you think they were being
pretty short sighted? Is this another problem that will go away
with 512K Macintoshes? It is a serious limitation for many
users who were planning to do real work on the Macintosh.
It seems likely that the Macintosh design team did NOT overlooked
this problem. They were probably forced to rushed the 1.0 finder
out the door before it was ready. Is the problem fixed in later
a version?
The Macintosh software seems to be full of simplifying assumptions
that make the machine look good for small examples, but fall somewhat
short for large examples. Besides the finder, there is the
length limitation on MacWrite. A preliminary version of MacDraw
(as demo-ed by its author at the West Coast Computer Fair) is
incredibly slow scrolling when there are large spline curves, even
when they are off the screen.
Don't get me wrong. The Apple Macintosh design team has done so
many things RIGHT. Conceptually, it is magnificent. It would be a
pity to find out that a ``real'' system takes more memory, a faster
disk, or algorithms they decided not to use.
-Gordoninfo-mac@utcsrgv.UUCP (info-mac) (06/02/84)
Date: 31 May 84 15:06:57 PDT From: uw-beaver!wert.pa@XEROX.ARPA Subject: Re: Slow and Impossible In-Reply-To: <8405260102.AA20256@ucbkim.ARPA> To: hamachi%ucbkim@UCB-VAX.ARPA (Gordon Hamachi) Cc: info-mac@SUMEX-AIM.ARPA The problem stems from the fact that folders are not disk files, but rather a relation on disk files. All the information that represents folders is placed in memory when the disk is booted, thus the number of folders affects the boot speed. I believe that this holds for file info, also. Note that when you eject the disk, you may still open folders, GET INFO them and files, too, etc. The result is faster operations on folders and files. Apple apparently did not anticipate that you would have enough files on a disk to make this a problem. scott