Why does Disk Cleanup take so much time and cpu?

Just a curiosity question. Disk Cleanup has been spending 100% of one of my cores for quite a while and still going. Seems to be spending a lot of time especially on Windows Update Cleanup.

Can't quite understand why deleting files should be such an intensive activity. Especially since it already spent quite a lot of time calculating what it could delete.

Why does Disk Cleanup take so much time and cpu? What does it do that is so intensive?

Windows compresses the WinSxS folder by removing replaced updates ad compressing files which can't be uninstalled and which are not used into diffs. This takes a lot of CPU power and thats why you see a high CPU usage.

You can analyze the CPU usage with xperf/WPA to verify this.

I can confirm that Windows Updates Cleanup takes almost 100% CPU usage, it's all about WinSxS compression and reintegration of updates:

I started cleanup first time after Windows install and it took 2 hours to finish 50%. From graph you can see, that at first lot of reading of small files from disk (second graph), and after 100% CPU usage for compression, and so on.

Just to put fire on the question, i had done on an inmutable virtual machine the next steps:

1. Boot a SystemRescueCD and mount the windows partition
2. List all files on disk to a log file (less than a minute)
3. Reboot onto Windows
4. Let cleanmgr do its job and take note of the time (more than eight hours)
5. Reboot onto SystemRescueCD and mount the windows partition
6. List all files on disk to another log file (less than a minute)
7. Reset back the inmutable virtual machine
8. Reboot onto Windows
9. Do a FOR /F ... to delete such files in an admin command prompt (cmd) and take note of the time (less than five minutes)

Please note i rebooted onto Linux SystemRescueCd just to be able to list all files, also the ones looked by Window and also to do such listing as fast as possible (no acl check, etc).

Also please note that on cleanmgr i only count only time after search ends (the search itself also tooks more than six hours).

So deleting the files is not the botle neck (the delete itself only need five minutes but cleanmgr takes more than eight hours).

The delete it self can go so fast since the host is a Linux, that speed is caused just because Linux caches all writes to the fixed size file that is used as the disk on the virtual machine (24GiB), and since i have 64GiB of RAM and i let to the Windows 16GiB it does not need to use SWAP neither PAGEFILE.SYS; also more, Linux can hold the full file on RAM (i tested with that file on RAM and delete times go done a lot, but cleanmgr time does not drop down).

Yes, if i put the virtual disk totally on RAM, cleanmgr time does not drop but if i manaully delete the files, that time drops down just a little (Linux write cache is great when you have 64GiB of RAM on it).

My configuration for the tests:

• Host: Linux 64bits distro over a hardware that main parts are AMD Deca Core 5GHz with 64GiB of RAM and a Sata Raid0 controller with two WD VelociRaptor HDDs (able to sustain a combined secuential write speed of near 1GiB/s and a 4K random write of 300MiB/s); cost is >ten thousand euros
• Guest: Windows 10 Home with 16GiB of ram and a Virtual disk of 24GiB

Test1: Having the 24GiB virtual disk on the physical harddisks Test2: Having the 24GiB virtual disk on the Linux host RAM

I am afraid that cleanmgr is doing something on the windows registry per each file it deletes (accessing the registry is very low).

Monitors i had:

• CPU usage on the Linux host and on the Windows Guest (most time between 0% and 1%, with pikes of 5%, no more)
• HDD usage on the Linux host (near 0% when cleanmgr was working, with pikes of 2%), Linux disk cache is really great avoiding dato be sent to real disk
• HDD usage on the Windows guest (most time between 2% and 15% when cleanmgr was working, with pikes of 28%)

So clearly cleanmgr is doing a lot of undetectable work, maybe sleep times? Maybe not, if it is accesiing registry, the CPU for that is not counted by Windows monitors, HDD on that is not used (registry is on RAM), etc., and each access to the registry can take more than a second... try your own program to access registry by opening the registry and closing it per each action versus letting the HK* opened... it is a great difference.

So if cleanmgr does for each file:

1. Open registry HK*
2. Consult whatever needs and/or do some writes on registry
3. Close registry HK*

It can take as much as two or three seconds per operation, and if it does one operation per file, it can take near one hour per each thousand of files... my count of files was just a little bit more than 40000 files, so 40000 files / 8 hours is processing one file each 1.3 seconds... on the other side, deleting them on a script (after knowing wich ones) tooks less than five minutes, that is deleting about 133 per second... a hufe difference.

So definitly cleanmgr time is not caused by the deletion it self! What else is it doing? Please M$ improve that speed!

One way to mitigate this problem and speed up the "Windows Update Cleanup" phase of "Disk Cleanup" a bit is to temporarily set a higher priority for the TiWorker.exe process for the duration of the so-called 'cleanup' activity.

In the Task Manager 'Details' pane, find TiWorker.exe and right-click to show a pop-up menu. For 'Set Priority," choose "Above Normal." For me, this increased the TiWorker CPU activity--from averaging around 16%--up to its full potential of 25% (on a 4-core machine).

Aside from the miniscule speedup--and possibly good feeling of accomplishment--this provides, there's little that can be done since apparently "Windows Update Cleanup" is coded in a way that, for some unknown reason, proceeds file-by-file, making the overall work horribly disk-bound.

And also, do know that the process is most probably not hung, and will indeed complete someday. To verify this (and to yet further distract yourself during this annoying wait time), you can check the 'Disk Activity' section of Resource Monitor (run "resmon.exe").