A few weeks ago, I decided to try the TrueCrypt route. To start, I created a file-based volume and did some testing in there. My benchmark was far from scientific, but I tested with things I do every day. I did a full SVN checkout of a code branch, opened and built it in Visual Studio, restored a SQL Server DB there, etc. Performance wasn't horrid, but it wasn't anywhere close to my bare-metal performance either- especially the SQL Server DB restore (took about 5x as long as on bare-metal). Most of the other operations I timed took anywhere from 1.5x-2x as long. There also doesn't appear to be a way to auto-mount file-based volumes, which means on every boot, I have to manually mount the volume (by entering the password), then restart the SQL Server. Gets old fast.
A file-based volume just wasn't going to cut it. Two weeks ago, I finally bit the bullet and decided to try hitting "Encrypt System Partition/Drive" (AFTER a full backup, thankyouverymuch). Making the leap easier to take was the fact that the process claims to be fully reversible. The experience was quite good- after choosing a password and generating keys, I burned a recovery CD (I'm glad the UI makes such an issue of this!). After the CD had burned and verified, it proceeded to background-encrypt the disk. I could theoretically use the system during this time, but decided not to try- just left it to crank overnight. When I came back the next morning, all was well. I rebooted and held my breath. I was presented with the TrueCrypt password prompt, followed by the normal Vista bootup process. Cool!
I went and retried my real world benchmarks, and much to my surprise, most of them were indistinguishable from their non-encrypted counterparts! The only one that was notably slower was a SQL DB restore- and that was only when the backup had a large log file. In case you didn't know: SQL Server won't allow you to resize the logfile on restore, so it allocates and zeroes an "empty" logfile matching whatever the server's logfile size was. We pre-allocate production server logfiles fairly large so they don't have to autogrow during large transactions. The side-effect is that restores to a clean DB are painfully slow. If I re-created the backup after truncating down to a reasonably-sized logfile, the restore performance was almost exactly the same as on a bare-metal, unencrypted drive.
Two weeks in, I'm really impressed with what the folks at TrueCrypt have done. 6.0a is as-advertised, and the performance hit is pretty minimal for just about everything I've tried. Looks like this problem is solved!