First off, let's begin by understanding just what it is that causes the performance degradation. Without knowing this, many people will suggest inadequate solutions (as I already see happening). The crux of this entire predicament basically comes down to the following fact, as cited from Wikipedia. Remember it, it's important:
With NAND flash memory, read and programming operations must be performed page-at-a-time while unlocking and erasing must happen in block-wise fashion.
SSD's are made up of NAND flash, and flash consists of "blocks". Each block contains many "pages". For the sake of simplicity, lets imagine we just purchased a shiny new SSD that contains a whopping single block of memory, and that block consists of 4 empty pages.
For the sake of clarity, I differentiate between empty pages, used pages, and deleted pages with ∅, 1, and X. The key being that there is a difference between each of these from the controllers perspective! It is not as simple as 1's and 0's. So, to start, the pages on our fresh drive look like so:
∅, ∅, ∅, ∅ (all empty)
Now, we go to write some data to the drive, and it ends up getting stored in that first page, thus:
1, ∅, ∅, ∅
Next, we write a bit more data, only this time enough that it requires two pages and so it ends up being stored in the 2nd and 3rd page:
1, 1, 1, ∅
We are running out of space! We decide we don't really need the initial data we wrote, so lets delete it to make room.:
X, 1, 1, ∅
Finally, we have another large set of data that we need to store which will consume the remaining two pages. THIS IS WHERE THE PERFORMANCE HIT OCCURS IN DRIVES WITHOUT TRIM!! Going from our last state to this:
1, 1, 1, 1
...requires more work than most people realize. Again this is due to the fact that flash can only erase in a block-wise fashion, not page-wise which is precisely what the final transition above calls for. The differentiator between TRIM and non-TRIM based SSD's is when the following work is performed!
Since we need to make use of an empty page and a deleted page, the SSD needs to first read the contents of the entire block into some external storage/memory, erase the original block, modify the contents, and then write those contents back into the block. It's not as simple as a "write", instead it's now become a "read-erase-write". This is a big change, and for it to happen while we are writing lots of data is probably the most inopportune time for it to occur. It could all be avoided if that "deleted" page were recovered ahead of time, which is precisely what TRIM is intended to do. With TRIM, the SSD either recovers our deleted pages immediately after the delete or at some other opportune time that it's TRIM algorithms deem appropriate. The important part though is that with TRIM it doesn't happen when we are in the middle of a write!
Without TRIM, we ultimately can't avoid the above scenario as we fill up our drives with data. Thankfully some newer SSD's go beyond just TRIM and effectively do the same thing as TRIM in the background at a hardware level without the necessary ATA commands (some call this garbage collection). But for those of us unlucky enough not to have either, it is important to know that writing zeros to the entire drive is not sufficient for reclaiming original performance!!!!! Writing all zeros to the drive does not indicate to the controller that the page in flash is free for writing. The only way to do that on a drive which does not support TRIM is to invoke the ATA secure erase command on your drive using a tool such as HDDErase (via Wayback Machine).
I believe there were some early SSD's that only supported TRIM upon deleting partitions or upon such things as Windows 7's "diskpart clean all", and not upon the deletion of individual files. This may be a reason why an older drive appeared to regain performance upon executing that command. This seems a bit hazy to me though...
Much of my knowledge of SSD's and hardware/gadgets in general comes from anandtech.com. I thought he had a great writeup explaining all of this but for the life of me I cannot find it!