Does Storing (lots of) Data on the Desktop Have Any Effect On Performance?

Topic

New Reply

I am doing a Windows 10 clean install to my son-in-laws Lenovo C40-05 all-in-one. 1 TB SSD, 16GB RAM & AMD A6-6310 (1.8 GHz) CPU.  (It’s more-or-less like a big laptop.)

It was purchased in 2016 and came with Windows 10 – ver. 1703.  It has been upgraded ‘on schedule’ since then but never reset or reinstalled.

Over time it has become increasing slower and that is why I’m doing the clean install.

Here’s my mystery.  My son-in-law’s computer style is to save everything on the desktop.  His desktop for the install I’m replacing has 128GB of data on it, including .DOCX, PDF, MP3 and MP4 files.

I don’t wish to generate a discussion on “computing styles”, but rather just want to find out if there’s any degraded performance by having lots of data stored like this on the Desktop. (Google yielded no help for me.)

Al T.

 

Reply | Quote

Replies

I don’t wish to generate a discussion on “computing styles”, but rather just want to find out if there’s any degraded performance by having lots of data stored like this on the Desktop. (Google yielded no help for me.)

In 30 years I’ve never encountered this circumstance, but here’s what my my gut is telling me.

If he has literally saved 128 gig of files directly on the desktop and has the “Show desktop icons” option enabled it seems quite possible (assuming the file count is likely multi-thousands) windows would become quite slow and perhaps unstable trying to graphically display multi-thousands of desktop icons on a single un-scrollable screen.

If this is the case, a clean install of windows may not help at all when all his files are put on the clean installed desktop.

Desktop mobo Asus TUF X299 Mark 1, CPU: Intel Core i7-7820X Skylake-X 8-Core 3.6 GHz, RAM: 32GB, GPU: Nvidia GTX 1050 Ti 4GB. Display: Four 27" 1080p screens 2 over 2 quad.

1 user thanked author for this post.

Al Taylor

Reply | Quote

Right you are, I think. A desktop and a profile that big is like a similar a “beer-belly” over the years. Slowing you down to mortality.

Sorry, you need to change to much cleaner computerbehavior

 

* _ ... _ *

1 user thanked author for this post.

Al Taylor

Reply | Quote

There is no reason that simply having a lot of “stuff” in the Desktop folder will make a computer slower in general. If there are a lot of files (thousands) on the desktop itself, it can slow the enumeration of the directory when you try to load the folder, and it could conceivably slow startup as the system enumerates the icons to be displayed on the desktop, but this is many, many times more files than would ever fit on a desktop.

If the number of files on the desktop itself are reasonable (few hundred or less), it really should not make any difference.

What is being described here sounds like a classic case of “Windows rot.” The phenomenon of Windows getting slower and slower is well-known and has never been linked, to my knowledge, to the number or size of files on the desktop or in subfolders thereof.

Starting back in the Windows 95 days, when the Windows desktop such that it is now made its debut, I developed a schema for storing my personal data where it was almost exclusively saved within folders placed on the desktop. I’ve kept that schema for more than 25 years now, and as it stands, I have more than half a terabyte of files within the desktop tree (though I have only ~40 files or directories in the root Desktop folder).

I use Linux, but there is nothing in particular that would make Linux much better at this than Windows, and indeed, I did use this same schema in my last Windows days in 2015 (though at that point it was probably closer to a quarter terabyte of files stored within the Desktop tree).

You can test the hypothesis. Simply move the large folders from the desktop to another location on the same volume (drive letter). Moving to the same volume is nearly instantaneous, as only the directories need to be updated to point to the same files. Then you can boot Windows and see if it has improved.

Be aware that any mass file move has a potential for data loss if something happens. This kind of thing is quite routine, but if there are files in there that the PC owner would be heartbroken to lose, they should already be backed up as a matter of course. Please do make sure they are backed up if they are important first!

Dell XPS 13/9310, i5-1135G7/16GB, KDE Neon 6.2
XPG Xenia 15, i7-9750H/32GB & GTX1660ti, Kubuntu 24.04
Acer Swift Go 14, i5-1335U/16GB, Kubuntu 24.04 (and Win 11)

1 user thanked author for this post.

Al Taylor

Reply | Quote

The Desktop is just an ordinary folder so it can have as many files as you want.
If you display all the icons it may take a little while to show, but once you switch to a full screen app it will not affect performance.
To test it, move the files to a sub folder – this doesn’t actually move the data, it updates the file location info.

Do you have multiple apps running in the background? Fire up Task Manager and check RAM use – less than 80% will be fine.
Is the disk nearly full? SSDs can slow down if they are less than 5% free – they need space to allow time for TRIM to behave.
Is TRIM actually working? See this post.

As always, make a full backup before doing anything.

cheers, Paul

1 user thanked author for this post.

Al Taylor

Reply | Quote

Ascaris wrote:

“Starting back in the Windows 95 days, when the Windows desktop such that it is now made its debut, I developed a schema for storing my personal data where it was almost exclusively saved within folders placed on the desktop. I’ve kept that schema for more than 25 years now, and as it stands, I have more than half a terabyte of files within the desktop tree (though I have only ~40 files or directories in the root Desktop folder).”

I have been doing exactly the same thing, since Windows 98, and continue doing it now with my Mac laptop. It is a way to keep things orderly arranged in the system’s desktop directory tree and uncluttered. I also have folders within folders within the Desktop folders.

Now I am curious, because it is a phenomenon I have certainly noticed but have never seen fully explained: what exactly causes “Windows rot”? Could it be mainly the applications’ blot that launches at start up?

So far, I have not noticed it much in my Mac, most certainly in a measure anywhere nearly as annoying as it used to be when I had been using a Windows PC for a comparable period of time as the Mac: close to five years by now.

One possibly related fact I think I should mention: all my Windows PCs had hard disks with at most 750 MB, in the end and earlier on nearly full with 98 and XP, and 2/3 full with the Win 7 PC, while this Mac has an 1 TB SSD, now less than 50% full — and also twice as much RAM, 16 GB, than the Windows 7 one, that had the most RAM of my Windows ones.

Ex-Windows user (Win. 98, XP, 7); since mid-2017 using also macOS. Presently on Monterey 12.15 & sometimes running also Linux (Mint).

MacBook Pro circa mid-2015, 15" display, with 16GB 1600 GHz DDR3 RAM, 1 TB SSD, a Haswell architecture Intel CPU with 4 Cores and 8 Threads model i7-4870HQ @ 2.50GHz.
Intel Iris Pro GPU with Built-in Bus, VRAM 1.5 GB, Display 2880 x 1800 Retina, 24-Bit color.
macOS Monterey; browsers: Waterfox "Current", Vivaldi and (now and then) Chrome; security apps. Intego AV

1 user thanked author for this post.

Al Taylor

Reply | Quote

“Does Storing … Data on the Desktop Have Any Effect On Performance?”
– No.

“The Desktop” really is just another data folder.
The only difference from any other folder is that Explorer displays, on the screen, the folder contents in a special/visual format.
To see it in ‘Explorer’ format, look at C:\Users\your-logon-id\Desktop .

So no, the quantity of data ‘on the Desktop’ is not a significant contributor to any performance consideration.

At multi-gigabytes of materials, I assume that there are many folders that contain many large files.

How does Explorer know which of the user’s folders is to be displayed on the screen?
In the Registry, see:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
– and –
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

2 users thanked author for this post.

OscarCP, Al Taylor

Reply | Quote

Ascaris wrote:

You can test the hypothesis. Simply move the large folders from the desktop to another location on the same volume (drive letter). Moving to the same volume is nearly instantaneous, as only the directories need to be updated to point to the same files. Then you can boot Windows and see if it has improved.

Actually, since I did a clean install, I did the reverse.

After the install I worked with the machine for a time, then after reading your reply, put all my son-in-law’s files onto the desktop (I’d backed them up to a portable drive).

Now as I’ve been continuing the setup process, my perception is that the computer is performing the same with the data on the desktop as it did without it.  Contrastingly though,  it is now MUCH faster than it was before the clean install.

Reply | Quote

Paul T wrote:

Do you have multiple apps running in the background? Fire up Task Manager and check RAM use – less than 80% will be fine. Is the disk nearly full? SSDs can slow down if they are less than 5% free – they need space to allow time for TRIM to behave. Is TRIM actually working? See this post.

For the “old” installation I looked at task Manager’s ‘Startup’ tab and there were 40 programs listed, all of them “Enabled”.  But after the clean install and the addition of the few programs SIL as requested, there are now 14 items in the Startup list and nine of them are disabled (by me).

RAM shows 20% usage (the machine has 16GB).

Trim is working on the SSD and it is only full to 40% capacity.

Thank you for your reply.

Reply | Quote

I’ve had an odd issue with this – it also used to affect the internet explorer cache folder as the names there used to be directly from the page concerned. The issue is traversal of the maximum path length, which whilst uncommon now, isn’t impossible to achieve if you nest folders in the GUI or have applications which work way down the appdata file tree (the old Dropbox versions could do it..) – eventually Windows tends to spot the problem on a disk check and restore sanity by “recovering” the folders – to root, thereby negating the issue. The exact limit varies greatly depending on the program using the folder so poor performance could be a poor application..

https://docs.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=cmd

https://social.technet.microsoft.com/Forums/lync/en-US/fbad33ee-b10b-4ab8-9370-a2af017ca46b/maximum-folders-in-a-folder-in-ntfs?forum=winserverfiles#:~:text=there%20is%20no%20hard%20limit,is%20limited%20to%2032767%20characters.

So, in summary pick a sensible and short user name without spaces or unusual characters and spread your data folders “wide” rather than “deep” and maybe consider turning of 8.3 file name generation unless you really do use any command prompt programs.. as that just makes more work.

As to “Windows rot” – it’s the mainly the result of a mash of short file segments (which defrag doesn’t resolve as rule) generated as free space by, and contained within, very large and active files like the registry, hibernation, Windows update and paging files which are hard to defragment as they’re inherently large and often “in use” (so it takes so long to parse the file details the optimisation process is interrupted by a change to the file  before optimisation in the background can begin). Command prompt defrag is more “configurable” and in 21H2 specifically mentions SSD (retrim option) so I guess it’s fine to use but you’d still have to really fill a very large desktop to see any performance degradation.. though it could kick in when your AV gets to background scanning the folder and tries to parse the content to generate a list if files to scan.

This fragmentation is relatively easy to evaluate (Maybe not for you, Al, but for others posting they might want to see the effect). Do a full clean-up of the rubbish in the installation, back up as you normally would, and time the start-up of Windows and a few choice apps opening by start-up script, image the Windows partition with DISM from recovery media and test extract the image (or be certain sure your backup works!), format the Windows partition and reapply the image to its original location. If that’s your issue the installation gets faster at finishing the test as the drive is transferring longer blocks of data rather than negotiating an increased number of shorter transactions, which is why if you didn’t build your PC your new OEM software was that good to start with (so they loaded lots of junk to slow it to normal and make the software bundle more attractive..) .. all the files are freshly and contiguously written, and it all goes downhill from there as Windows thrashes about rewriting things in small free spaces.

Yes, I know I’m forgetting the stuff about 400k drives and sector alignment.. for most part that’s a server thing.. I never bothered, nobody complained.. but as we used the ADK for deployment, it might even have sorted that itself.

https://social.msdn.microsoft.com/Forums/vstudio/en-US/58b36747-800c-499c-ae19-f54b267ad057/how-to-check-the-ssd-4k-alignment-programmatically?forum=vbgeneral

 

2 users thanked author for this post.

Al Taylor, OscarCP

Reply | Quote

oldguy wrote:

As to “Windows rot” – it’s the mainly the result of a mash of short file segments (which defrag doesn’t resolve as rule)

The machine has an SSD. There are no fragmentation issues with an SSD so that is not the cause.

oldguy wrote:

very large and active files like the registry

Registry file are not particularly large. Mine take up less than 5MB.
To see your registry files:
1. Open a Command Prompt (Win R, cmd)
2. Type the following and press Enter: dir %userprofile%\nt*.* /ah

cheers, Paul

Reply | Quote

You are not thinking of the whole picture. Think not only of the layout of the actual data on the drive, but the TIME needed to get it. In the older spinning drives, the time to get a track of data off the media and into the drive controller was long (which is why spinning faster was better!) and the seek time to the track was the other long process which is why getting files into contiguous blocks on the same or adjacent tracks helped a lot. The time for the drive controller to request the particular LBA was insignificant back then, but now the drives are electronic those mechanically derived delays are no more, so the main concern is the number of transactions to attain the required data.

I’d hope all drives now support native command queueing, but there is still a time difference between requesting a file as a series of individual LBAs (to effectively fill the command queue, as the LBA (large block address) detail needs to be transferred to the controller as the controller just stores what its told where it’s told (by the LBA) and retrieves it, it knows nothing of the file system..)

There’s a new thing where a transaction transfers a “frame information structure”- basically a whole lump of data for the OS to chew through as one transaction, (so of course, the less chewing required, the quicker the required data is extracted from the transfer to the right memory locations) and I guess Windows 10 is going to use that method if it can the same way LBA replaced CHS (moving the data location overhead to the drive electronics) some years back.. Here’s the (in depth..) article I found it in.

https://www.mindshare.com/files/ebooks/SATA%20Storage%20Technology.pdf

Of course if an application is issuing legacy commands to the drive (i.e. the system has an old sata driver, or a controller working with a compatibility driver, or through BIOS support like mine) and the sectors are incorrectly laid (as with a SSD the sectors are purely a data formatting consideration) then the delays there would combine to take the edge off.. (which I’m pretty sure I have seen!)

Next time my machine grinds to a halt I intend to give defrag /l /o a try, rather than the plain command.. on my BIOS supported SSD RAID AHCI and maybe see what /k does as well. (if there’s enough space.. seems “unlikely”, 60Gb drives.. RAID1 to get some movement.)

 

Reply | Quote

Thanks, Paul_T. Yes, that is quite as I understand it is for the SSD; I was curious about the “Windows Rot”, that is to say, in Windows computers, which now has been clarified is only for Windows PCs with an HDD. I was not thinking, when I asked my question, on file fragmentation. I thank those of you who have made things clear to me.

I no longer use Windows, but having not heard of “Windows rot” before, I started wondering if it was the annoying delay caused by software blot, or too many things launching at start up. Or too much paging, perhaps due to insufficient RAM and disk space.

Ex-Windows user (Win. 98, XP, 7); since mid-2017 using also macOS. Presently on Monterey 12.15 & sometimes running also Linux (Mint).

MacBook Pro circa mid-2015, 15" display, with 16GB 1600 GHz DDR3 RAM, 1 TB SSD, a Haswell architecture Intel CPU with 4 Cores and 8 Threads model i7-4870HQ @ 2.50GHz.
Intel Iris Pro GPU with Built-in Bus, VRAM 1.5 GB, Display 2880 x 1800 Retina, 24-Bit color.
macOS Monterey; browsers: Waterfox "Current", Vivaldi and (now and then) Chrome; security apps. Intego AV

Reply | Quote

“Windows rot” is an old wives’ tale.  Keep it clean and tidy and there will be no degradation in performance.  The “need to do a clean install” myth is just that, a myth.

Reformat/Re-install

Partitioning Options

Disk Cleanup

Always create a fresh drive image before making system changes/Windows updates; you may need to start over!

We all have our own reasons for doing the things that we do with our systems; we don't need anyone's approval, and we don't all have to do the same things.

We were all once "Average Users".

Computer Specs

3 users thanked author for this post.

JohnW, Fred, joep517

Reply | Quote

bbearren wrote:

Keep it clean and tidy and there will be no degradation in performance.

In the case of the clean install I did for SIL, since the time back when the computer was initially set up in 2016, both he and my daughter have changed jobs and are also living in a new state.  As well, their children have all graduated and moved away.

The “old” install showed 147 items in Control Panel’s “Programs and Features”, while the clean install (which includes only the programs they now want/need) lists 33 items.

I could have tried just uninstalling the unwanted programs, but I wonder if that would have resulted in as “clean and tidy” a machine as does the clean install I just did.

If I’d used a program like Revo to do all of the uninstalls, it’s likely a goodly amount of ‘clutter’ would have been removed vs. conventional uninstalls; however, doing so would have been very time consuming for one, but also it’s likely that at least some ‘remains’ of programs would still have been there afterwards to clutter things up.

FWIW, the entire clean install took me about 5 hours, and about a third of this did not require any of my time since Windows was kept busy updating itself.  (I did have to chase down two ‘Unknown Devices’ after the updates were done, but that went well.)

Thanks for adding to the discussion.

Reply | Quote

The junk in the early Windows install media was significant (I’m probably thinking of 1706?) – Office 365, onedrive, Zune (does that player exist now? Wikipedia indicates it was discontinued in 2012..) as well as “hot tiles” for other things I didn’t need (emptied C:\Users\Default\AppData\Local\Microsoft\Windows\Shell\defaultlayouts.xml “start:Group” sections before creating my actual account and removing the out of box one).

I pulled the junk I wasn’t going to use off with DISM where it couldn’t be uninstalled (Onedrive is the oddball – it’s installed from the run key in the default registry hive which forms the base for new accounts) and these items don’t seem to reappear so I suspect a flat installation of 21H2 would probably be “cleaner” though I haven’t had to reinstall yet.

I’m bemused by the install times quoted – I found ages back that optical disks and USB keys were just about the slowest way to go about installing. I capture the mounted ISO with DISM, lay out a UEFI file system on a clunky (salvaged from PVR!) IDE hard disk in an old USB caddy but up the boot partition to 30gb to accommodate the applied image of the recovery media, place the WIM archive of that media on what would be the Windows partition in normal usage, and on my decade old heap that boots UEFI fine allowing the setup files to be stationed in a folder on the root of the Windows drive, ready to run setup with an answer file from inside the previous Windows install.

To do a bare metal on my machine is a little fiddly – I prepare the target drive as per the external drive (without the image) and boot the internal drive to command prompt in recovery options, change to the ramdisk (x:) and repartition and format the main drive areas where required, the connect the caddy and apply the installation files image as before, then I change to the installations files directory, remove the external drive, and “rescan” in diskpart so when I run setup Windows is convinced by the variables in memory that it can boot the internal drive (all this mainly as my BIOS supported RAID has issues with just that!) and setup sees only one boot partition to set up the Windows 10 boot on (yes it can, and does, decide to keep using the boot on the external drive if it detects it!!).

That gets Windows on a lot faster.. That said, nothing like as fast as applying a FFU image you captured having got the installation to the user setup wizard and hit the hotkey for audit mode and shut down from there before capture. That said my FFU image is now so outdated I would be as well to just go for a bare metal reinstall and have a cup of tea while setup is running.. but I tried it just to see, it’s a quick single stage imaging process if you don’t mind driving it from a command prompt..

Either case the folder with setup files can be removed- in audit mode if you want to image the drive. If you’re not imaging and you have a mechanical drive, run defrag at this point, so any leftover fragments get neatly stacked in the cleared space near the start of the drive. Next time I do this I’m aiming to try the extra switches on 21H2 (or newer) defrag.

BTW if your simply reinstalling and you know your drivers are not the problem, you could make your life easier by using (in elevated command prompt) pnputil /export-driver * {target folder somewhere safe} to squirrel them away, and after reinstalling get them back with pnputil /add-driver {target folder somewhere safe}\*.inf and reboot when that’s done. That also works in audit mode.. but be aware audit mode is only for installing software and “testing” installations.. not daily use. It’s effectively the administrator account you’re using in that mode.

 

1 user thanked author for this post.

Al Taylor

Reply | Quote

oldguy wrote:

I intend to give defrag /l /o a try, rather than the plain command.. on my BIOS supported SSD RAID AHCI

RAID internal layouts don’t necessarily reflect Windows file structure, especially if using RAID 0 or 5. I would leave the hardware to manage the files and rely on the speed of the SSDs to do the rest.

cheers, Paul

Reply | Quote

Perhaps I’m showing my age here, but do people remember “Roaming Profiles”, which required the contents of one’s desktop to be loaded down from the server at logon time?  Disastrous for large desktop contents over slow lines…

BATcher

Plethora means a lot to me.

Reply | Quote

Still used in the corporate world where hot desking is required.

cheers, Paul

Reply | Quote