GrandmaG wrote:
I read this entire post to hopefully get some info as to why adding RAM to a 2014 iMac didn’t seem to make any difference. I didn’t find the answer here and I will research it later. However, I found this statement that you made quite interesting. I found an old HDD in my safe deposit box, plugged it in, and all the files are still there. Unfortunately, most of the files were created with software I no longer have because with newer systems along the way, they were no longer supported.
I was in the process of using an external SSD to store my Lightroom catalog and recent photos. I had nothing but trouble with this WD SSD and went back to using my trusty external Seagate 1TB HDD. After reading this statement of yours, I think I made the right choice.
My computer isn’t exactly slow, but not as fast as I would like while editing in LR/PS. You seem to know a lot about computers. Do you know both Apple and Windows OS?
I read this entire post to hopefully get some info... (
show quote)
GrandmaG, you are one smart lady. I only use Seagate disk drives (I used to also use Conner--which Seagate acquired--
and Quantum until it was acquied by Maxtor). Back in the era of serial SCSCI bus interface, Seagate drives were used
in mission-critical systems in the telecomm industry.
I haven't bought any product made by WD since the 1990s, when one of the engineers in my group found a bug in a WD
floppy disk controller chip we were shipping in a product. No problem--many chips have bugs--the manufacture just gives
you a workaround. Except WD wouldn't admit the bug--even after we faxed them a photo of the o-screen that proved it
wassn't following the correct timing. We were buying the part to put it in our product--any company that will lie to its
own OEM customer doesn't get my business.
I am not a not an Apple guy. But here are some questions that come to mind:
1. Does MacOS presence of the additional RAM? I think how you check this depends on
the MacOS version.
2. Have you tuned the OS for additional RAM? Chances are a number of parameters
were set for the amount of RAM it was shipped with.
3. Not all RAM is the same. Adding slow RAM could slow down a system--especially
if paging or swapping wasn't the bottleneck. The fastest RAM is static RAM--SRAM--
no dynamic refresh. Very expensive.
4. You aren't going to like this: MacOS is s slow operarting system. That's why Apple
doesn't make a server. God and all his Angels couldn't make MacOS go fast. That
doesn't mean it's not a great single-user home computer OS. It just means if you get
enough concurrent processes going, or mutliple users, or lots of concurrent IO (e.g.
network traffic) it gets really s-l-o-w.
MacOS is based on the NeXTSTEP OS which Apple got when it acquired NeXT Computers.
NeXT OS in turn was based on the Mach microckernel from Carnegie Mellon Univeristy.
NEXT OS also used display PostScript (wonderful, but slow), Objective C (non-standard),
and an object-oriented application layer. I have no idea if Apple kept any of that--but they
definitely kept the Mach microkernel.
I remember when Carnigie Mellon had a booth at the Uniforum trade show to promote
Mach. Every major UNIX OEM manufacturer evaluated it, as did Unix Systems Laboratories,
and none adopated it--they all stuck with monolithic kernels. The reason is performance.
Micorkernels are enormously elegant. Mach uses message passing. I you are a user-level
process that needs something from a disk, you call an an OS entry point, whch queues a message
to the disk manager, that queues a message to the appropriate drive manager. Then the driver
resplies to the disk manger, then the disk manager replies to the kernel, which returns from the
system call. Too many layers--slower than molassis in January. But a tiny, simple kernel--
very elegant, great as a academic research and teaching.
In a monolithic OS (like all other UNIX implementations or MS NT/XP/Vista/Windows7/10
it's a calling interface all the way down to the device driver. The application calls the OS
entry point, and that calls the device driver.. No queuing messages: just push arguments on
the stack then jump. Very fast.
Sorry I can't be more specific--but like I said, I'm not an Apple guy.