13
1
Just out of interest, what is the reason for deletion times to be periodic often? In Windows 8, the deletion dialogue window shows deletion speed in a diagram.
If there is no reason, of course that would be an answer, too.
danijar
Posted 2013-08-06T16:13:42.113
Reputation: 389
5
There are a few reasons:
Data Continuity: NTFS is implemented where it writes sequentially across a disc, so if you edit a file - NTFS may have to store the changes in a non-contiguous sector on your hard disc. That means that to delete a file, it may need to jump from sector 2 to sector 100,000 (hypothetically, of course) and then back to finish the file. Then it finds the next sector of the next file to delete and again could repeat that process.
Data types: Say you are deleting a folder in temp, it may contain large files and small files. Some of those will be quick to process and others may be slower (whether that is size or complexity of data - i.e. how many sectors need to be processed to finish an "item")
@Ramhound mentioned the "items per second" piece, which appears to be confirmed by your deletion dialog (Speed: 1.082 items/s). So deleting a huge file, a non-contiguous file, or a small file all plays a role in the number of items per second.
CPU Prioritization: This stuff is done in clock cycles, so it is likely that your CPU may be running other processes during the cycle and that may affect the speed (this is conjecture on my part)
nerdwaller
Posted 2013-08-06T16:13:42.113
Reputation: 13 366
3Windows/NTFS doesn't zero out occupied blocks when deleting files. Large or small, contiguous or non-contiguous doesn't matter. – abstrask – 2013-08-09T08:44:43.207
@abstrask - I didn't say it does zero anything out. However, it does have to jump around the $BitMap (file) to each cluster and mark it as free to use (i.e. "deleted"). Opening and editing a file (at any level) does take resources and having to jump around in it does take overhead and can absolutely slow you down. If the file is large - it takes longer to edit, if the file is non-contiguous - it takes a little longer to seek. – nerdwaller – 2013-08-09T13:05:09.370
1Each cluster is represented by a bit in the $Bitmap file. Assuming the default allocation unit size of 4 KB, the allocation reference for a 100 KB file accounts for about 3 bytes in the $Bitmap file. A large file, say 1 GB, takes up 32 KB in the $Bitmap file. Even if $Bitmap was heavily fragmented, the hard drive would only have to skip between 32 KB / 4 KB/cluster = 8 clusters, to mark the 1 GB file's clusters for deletion. Yes, more bits have to be flipped to delete a large file, but it's hardly measurable and would definitely not cause the largish visual bumps shown in the screenshot. – abstrask – 2013-08-10T18:13:36.730
4you have 100,000 files in the folder, they are all different sizes, the measurement is Items per second so the smaller the items the faster the items will be deleted. – Ramhound – 2013-08-06T16:39:51.717
3@Ramhound, It doesn't seem that this is related to varying file size. The sinusoidal nature of the graph is too regular. – GaTechThomas – 2013-08-06T18:44:09.340
I'm wondering if it is related to position on the hard drive. Is this disk or SSD? Also, do deletes look the same if antivirus is disabled? – GaTechThomas – 2013-08-06T18:47:03.930
@GaTechThomas It's a solid state drive. Yes, it doesn't depend on antivirus software. – danijar – 2013-08-06T20:17:03.187
1Windows doesn't zero out occupied blocks when deleting files. Deleting a large file shouldn't take any longer than deleting a small one. The culprit is more likely the sheer number of items. Are they in many subfolders? There's a substantial overhead, when dealing with many files (big or small) - regardless if you're deleting, copying or moving. – abstrask – 2013-08-08T21:45:29.913
2Caching of some sort? Bunch of delete requests get flushed at the peaks of the graph? – Jesse Slicer – 2013-08-09T19:39:46.173
@JesseSlicer That sounds reasonable. – danijar – 2013-08-09T20:15:21.277
1I've seen this too, sometimes with much larger waves. – Moshe Katz – 2013-08-12T18:44:58.767