At the device level, SSD drives function entirely differently then conventional mechanical disks. As a result, the way that operating systems traditionally use these devices lead to progressive performance degradation and even shortened lifespan. Technology was needed to offset this failing. Enter TRIM. Apple introduced it in 2011, but believe it or not, even today, Apple refuses to automatically enable TRIM for 3rd party SSD drives. Not only that, but if you manually enable it yourself, it is then disabled during any OS upgrade (i.e. 10.9.1-10.9.3). You can check your TRIM status from the System Profiler/System Information under SATA by selecting your device. I switched my favorite utility from Chameleon SSD Optimizer to Trim Enabler. I made the change for two reasons. First, Chameleon has some compatibility issues. Second, Trim Enabler has a feature to check on startup. Makes it easier to reenable after a software update.
I found a great utility to enable TRIM on 10.6.8-10.9.5: Trim Enabler
Don’t forget to reenable it after each OS X System Update.
Technical Details from Wikipedia:
Because of the way that file systems typically handle delete operations, storage media (SSDs, but also traditional hard drives) generally do not know which sectors/pages are truly in use and which can be considered free space. Delete operations are typically limited to flagging data blocks as “not in use” in the file system. Contrary to, for example, an overwrite operation, a delete will therefore not involve a physical write to the sectors that contain the data. Since a common SSD has no knowledge of the file system structures, including the list of unused blocks/sectors, the storage medium remains unaware that the blocks have become available. While this often enables undelete tools to recover files from traditional hard disks, despite the files being reported as “deleted” by the operating system, it also means that when the operating system later performs a write operation to one of the sectors, which it considers free space, it effectively becomes an overwrite operation from the point of view of the storage medium. For traditional hard disks, this is no different from writing an empty sector, but because of how some SSDs function at the lowest level, an overwrite produces significant overhead compared to writing data into an empty page, potentially crippling write performance.
SSDs store data in flash memory cells that are grouped into pages, with the pages (typically 4 to 16 kB each) grouped together into blocks (typically 128 to 512 pages per block, e.g. totaling 512 kB per block in case of the 4/128 combination). NAND flash memory cells can only be directly written to when they are empty. If they are considered to contain data, the contents first need to be erased before a write operation can be performed reliably. In SSDs, a write operation can be done on the page-level, but due to hardware limitations, erase commands always affect entire blocks. As a result, writing data to SSD media is very fast as long as empty pages can be used, but slows down considerably once previously written pages need to be overwritten. Since an erase of the cells in the page is needed before it can be written again, but only entire blocks can be erased, an overwrite will initiate a read-erase-modify-write cycle: the contents of the entire block have to be stored in cache before it is effectively erased on the flash medium, then the overwritten page is modified in the cache so the cached block is up to date, and only then is the entire block (with updated page) written to the flash medium. This phenomenon is known as write amplification.