Question Copy/Paste speed difference: macOS vs. Windows PC

[Endre]

A friend of mine owns a macOS laptop (CPU: Intel i5, 16GB DDR4, OSX on SSD). He copied a 33GB file from his internal drive to the desktop in about 1 second!
I own a Desktop PC (CPU: Intel i7-9700K, 16GB DDR4, Windows 10 x64 on SATA-SSD). I copied a 16GB file from Local Disk C to the Desktop in... A LOT LONGER TIME THAN 1 second!

QUESTION#1: Why is Windows copying files so slow?
QUESTION#2: Would an M.2 NVMe SSD or an Intel Optane Memory match the speed of the macOS?

 

[ElectrO_90]

You can't transfer 33GB in one second, impossible with todays technology.
He sent a shortcut to his desktop in 1 second, sure.

 

[Endre]

No, he did not send a shortcut! He copied the file, he checked the file properties in both places (internal and desktop) and they were both 33GB files!

 

[USAFRet]

33GB "in about 1 second " is impossible with current consumer grade technology.

Given 2 physical drives, NVMe -> NVMe can do maybe 1GB/sec.

His "desktop" is just another location on that same physical drive, and it just rewrote the file allocation table.

 

[Endre]

I copied my 16GB file from Local Disk C to Desktop, which is also located on drive C, and it took some time!
He also copied the file, and immediately renamed it in the root folder! So now he was having 2 different files of 33GB!

 

[TJ Hooker]

https://en.m.wikipedia.org/wiki/Copy-on-write

Apple's file system does a form of copy on write, so when you initially copy paste you're basically just creating a link to the original, and from there when you make changes it just saves the delta.

 

[USAFRet]

I copied my 16GB file from Local Disk C to Desktop, which is also located on drive C, and it took some time!
He also copied the file, and immediately renamed it in the root folder! So now he was having 2 different files of 33GB!

Unless you two have subverted the laws of physics, it cannot do this.

What physical drives are in this system? Size, type, make, model, etc.

 

[Endre]

Unless you two have subverted the laws of physics, it cannot do this.

What physical drives are in this system? Size, type, make, model, etc.

I don’t know exactly, I’ll ask him the exact specifications, then I’ll get back to you.

 

[Rogue Leader]

https://en.m.wikipedia.org/wiki/Copy-on-write

Apple's file system basically does copy on write, so when you initially copy paste you're basically just creating a link to the original, and from there when you make changes it just saves the delta.

THIS.

I use a brand new MacBook Pro every day for work which is actually faster than what he has based on the specs you gave. Its due to the file system, its not a real copy when its done internally like that.

 

[Endre]

https://en.m.wikipedia.org/wiki/Copy-on-write

Apple's file system basically does copy on write, so when you initially copy paste you're basically just creating a link to the original, and from there when you make changes it just saves the delta.

So, with other words it didn’t actually copy the file, it just pretended as if?...
But what did the OSX after he renamed the root file? It “keeps in mind” both names of the same file?

 

[jsmithepa]

He either did a MOVE, or it was a shortcut thingy. No Nobel Prize for u today.

 

[Endre]

THIS.

I use a brand new MacBook Pro every day for work which is actually faster than what he has based on the specs you gave. Its due to the file system, its not a real copy when its done internally like that.

OK

 

[Endre]

Unless you two have subverted the laws of physics, it cannot do this.

What physical drives are in this system? Size, type, make, model, etc.

His computer is this: MacBook Pro “Core i7” 2.6 15” (6-core CPU, 2.6GHz, 9MB cache; 16GB DDR4-2400MHz).
He just copied the 32gb ISO file, then immediately renamed the other one.

 

[Solandri]

His computer is this: MacBook Pro “Core i7” 2.6 15” (6-core CPU, 2.6GHz, 9MB cache; 16GB DDR4-2400MHz).
He just copied the 32gb ISO file, then immediately renamed the other one.

It's a new "feature" of OS X. When you make a copy, it just makes a hard link back to the original file. That's why it seems to finish immediately. (A hard link is like a shortcut, except there's no difference between the original file and the new link. That is, one is not the original while the other is a shortcut. They're both link to the same data on the drive as if they were both the original. The file keeps track of how many hard links are pointing at it, so it knows to delete itself when the last link is deleted.)

The copy is not really made until you actually make changes to the file (renaming the file does not count as a change to the file, since all you're doing is changing the link name). So if he edited the file to make it different from the original, then OS X will write a completely new copy

There's nothing really wrong with doing it this way. Other OSes don't because usually when a user makes a copy of a file, they're doing it for peace of mind. So they know they'll have a local backup of the file in case something happens to the original. With the new OS X method, if you made a copy of a file as a safety backup, and the file somehow became corrupted, both copies would be corrupted since they're actually both pointing to the same file. I'd argue that the OS X method is functionally worse since normally if you need to copy a large number of files, you can start the copy and go watch TV or something until it finishes. But with the OS X method you'll be stuck waiting for the actual copy to be made because it'll only happen while you're at the computer working.

I suspect the reason Apple went ahead with this change is because one of the consequences of ditching Samsung as the source for their flash NAND is that the new Macbook Pros have some of the slowest 4k read/write speeds I've seen in a modern SSD. I'm talking like 10-20 MB/s, when a modern Samsung NVMe SSD can hit 70 MB/s at 4k reads, 150 MB/s at 4k writes (QD=1). Deferring the copy to when a change is made to the file helps spread out in time a copy of a bunch of files (like a folder), so this slowness is less noticeable to the user.

Look at the non-QD32 CrystalDiskMark 4k benchmarks in these reviews if you don't believe me.
https://www.notebookcheck.net/Apple-MacBook-Pro-15-2018-2-6-GHz-560X-Laptop-Review.317358.0.html
https://www.notebookcheck.net/Apple-MacBook-Pro-13-2018-Touch-Bar-i5-Laptop-Review.316648.0.html

https://www.notebookcheck.net/Lenovo-ThinkPad-X1-Extreme-i7-4K-HDR-GTX-1050-Ti-Max-Q-Laptop-Review.335608.0.html

The other reason I can think of is because the SSD on the newer Macs is soldered to the motherboard and can't be upgraded. Due to the high prices Apple charges, most buyers are probably going to get Macbooks with relatively small SSDs. So deferring copies until the file is actually changed to be different from the original helps save space.

 

[EmilyLewis]

While the data is not physically copied to the hard drive. For example, if copying a 500MB file from internal hard disk to USB drive, the data might be "read" into the OS's RAM cache, and being written to the USB drive, and while it is still writing, the file is already reported as "finished copying" and the speeding of copying is therefore stated inaccurately high.

 

[Rogue Leader]

While the data is not physically copied to the hard drive. For example, if copying a 500MB file from internal hard disk to USB drive, the data might be "read" into the OS's RAM cache, and being written to the USB drive, and while it is still writing, the file is already reported as "finished copying" and the speeding of copying is therefore stated inaccurately high.

Thanks, 8 people stated basically this 3 months ago. Please stick to new current threads.