Why disable Windows indexing on SSDs?

[idata]

(I've posted this same question on another web forum before. I'm not a big fan of cross-posting, but this question is bugging me and I'd need to get a wider audience for it, so I'm now trying it here.)

It's a very commonly repeated recommendation for SSD users to disable the Windows indexing service on their SSD drives. And I don't understand it.

So far, I've seen two justifications for this:

1) You reduce the extra write cycles that would otherwise shorten the life of the drive

2) SSD seek times are so low that you don't really need indexing

I'd agree with the first justification if the capability to do quick keyword searches is less important to you than the longevity of your SSD. Unless you can configure your index files to reside on a secondary conventional hard drive (which you can, thus eliminating all indexing writes on the SSD) and you're okay with losing the capability to perform quick searches, then, yes, you can probably extend the life of your SSD a little bit by disabling indexing. But, don't expect claim number 2 to compensate for the drawback of disabling indexing, which I'll get to next.

The second justification is the one I can't wrap my mind around. Could someone please explain to me how fast seek times will help me when I'm doing a keyword search on my drive?

Finding a keyword in a file on an unindexed drive is not a matter of merely quickly seeking to a number of files. You also need to read the contents of each file to see if there is a match. Seek times of SSDs are a couple of orders of magnitude lower than hard drives, but their read speeds are better only by a factor of 2 or 3 (and sometimes not even that much). And you'll be doing much much more reading than you'll be doing seeking when you're looking for a keyword in file contents on an unindexed drive.

Here's a simple example: Let's say you have a drive volume that has 50,000 files on it and you're looking for the first file with the keyword "rosebud" in this entire volume.

Here's how long it would take on an indexed hard drive:

- Time to seek to the index file: 15 ms

- Time to find the index entry for "rosebud" in it: (conservatively) 500 ms- Time to read the file name listed on this index entry: (negligible, but let's say) 50 ms- Time to seek the discovered file: 15 ms

Total time: less than 1 second

Here's how long it would take on an unindexed SSD, assuming the correct file is happened upon after scanning "only" 20,000 of the files on the volume:

- Time to seek to 20,0000 files: 0.1 x 20,000 = 2,000 ms

- Time to read contents of 20,000 files and look for a match: (optimistically) 1 x 20,000 = 20,000 ms

Total time: 22 seconds

Am I smoking something, or is everyone else? Has anyone who claims that low seek times eliminate the need for indexing given this any real thought?

One counter argument I've also seen is that searches that are on file metadata (filename, date, etc.) do not require reading the contents of any file and it might be this type of searches that people have in mind when they claim that fast seeks eliminate the need for indexing. The problem with that claim is that the core benefit of indexing is to quicken searches through contents of files. If you know you'll never be doing file content searches then, yes, you can disable indexing. But that doesn't mean that you don't need indexing "because of" your fast seek times. It only means you don't need indexing because you don't need content searching.

So, telling people (especially inexperienced users) that "you don't need indexing on SSDs because their seek times are so low" is misleading. When someone reads something like that, they would take it literally and assume that SSDs enables everything to be just as quick without indexing and that's simply not true.

[idata]

This was one tip I didn't bother with. Actually, I WANT my indexes on my fastest drive! I'm about to hit 500 GB in host writes, which means I've used about 25 days worth in 3 months, so I don't see any reason to change.