X-25M update

Coming up on a month of living with the X-25M SSD... Right after my original post, Intel released a firmware update to address the slowdown issues. I, of course, applied it immediately, with no issues.

A month later, things are still going great. The one nasty side effect is that this drive has RUINED me for working on anyone else's computer (including my home PC). Everything else just feels like molasses when compared to my work laptop.

I also have to be really careful with SQL Server performance. I was writing a little tool that did some LINQ to SQL stuff recently, and the way it was doing a GroupBy() hid the fact that it was doing hundreds of queries on the DB. Normally, I'd notice such a thing because what should be a lightning fast query would cause the machine to grind for a few seconds. With the SSD though, even the hundreds of queries came back lightning fast. I had to run SQL profiler to see what it was really doing- glad I did, because I was able to tweak the query to run fast on "normal" machines with a single DB query and do the fancy grouping behavior in memory after the fact.

Anyway, I'm still giving this thing two big fat thumbs up!

Fun with LINQ

I had a little problem at work today that smacked of "I bet there's a clever LINQ way to do this without using local variables and side effects". The problem: given a list of whatevers, create a dictionary of whatevers whose key is the original index in the list. Don't ask why- that'd take too long to explain.

After screwing around with a false start (yield return in the key selector lambda of ToDictionary- disallowed by the compiler), I came up with something really gross-looking using Aggregate. Then I posed the problem to a couple of coworkers. Here's what we all came up with. Which one do you think runs the fastest? The answer may surprise you.

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            List<string> input = new List<string> { "1", "2", "3", "4", "5", "6" };

            // #1: Matt's original with local var
            var sw1 = Stopwatch.StartNew();

            for (int i = 0; i < 4000000; i++)
            {
                int index = 0;

                var dic = input.ToDictionary(k => index++);
            }

            sw1.Stop();

            // #2: Matt's "yikes" version with .Aggregate
            var sw2 = Stopwatch.StartNew();

            for (int i = 0; i < 4000000; i++)
            {
                var dic = input.Aggregate(
                    new { Index = 0, Dictionary = new Dictionary() },
                    (a, t) => { a.Dictionary.Add(a.Index, t); return new { Index = a.Index + 1, Dictionary = a.Dictionary }; }
                );
            }

            sw2.Stop();

            // #3: James' "list ordinal hack" version
            var sw3 = Stopwatch.StartNew();

            for (int i = 0; i < 4000000; i++)
            {
                var dic2 =
                  input.Aggregate(new List<int>(), (lst, elt) => { lst.Add(lst.Count); return lst; })
                       .ToDictionary(k => k, v => input[v]);
            }

            sw3.Stop();

            // #4: James' "nasty list hack + .Aggregate" version
            var sw4 = Stopwatch.StartNew();

            for (int i = 0; i < 4000000; i++)
            {
                var dic =
                  input.Aggregate(new Dictionary<int, string>(), (d, elt) => { d[d.Count] = elt; return d; });

            }

            sw4.Stop();

            Console.WriteLine("Done. 1:{0}ms, 2:{1}ms, 3:{2}ms, 4:{3}ms", sw1.ElapsedMilliseconds, sw2.ElapsedMilliseconds, sw3.ElapsedMilliseconds, sw4.ElapsedMilliseconds);

            Console.ReadKey();

        }

    }

}

Intel X25-M SSD on the dev laptop

Just today replaced my 7200rpm drive on my main dev laptop with a 160G Intel X25-M SSD. Been drooling over this since it came out, and my expectations were very high. Two words: holy crap. In just about every way, it's as fast as I hoped. Some of the high points:

- Boot time (Server 2008): 15sec, down from 45sec.
- SQL Server 2005 Database restore (30G DB): 9min, down from 45min.
- Query large SQL Server table (3m rows) on an unindexed column: 20sec, down from 3min
- VS2008 load of our main .sln: 13sec, down from 50sec
- Full rebuild of our main .sln: 39sec, down from 1min 15sec.

The rebuild didn't go down as much as I'd hoped, but then I tried doing it DURING the large DB restore mentioned above. Wow! Previously, my machine was completely useless during the DB restore. With the SSD, the restore chugged away, and the full rebuild took 45s, only 6s longer than an "unloaded" machine.

Overall the machine is very snappy feeling, and app startups are noticeably faster. I did the February pre-SP2 hotfix rollup for Outlook 2007, which contains a bunch of SSD-friendly fixes, it's also very snappy now even with my bloated mailbox.

Really pleased with the first day performance. Hopefully it holds out- I'm almost planning on needing to do an image-wipe-restore process every couple of months (to combat the well-documented internal fragmentation slowdowns), but we'll see how these metrics hold up over time first.

Squeezebox Boom

After visiting a friend in New York a couple of weeks ago and playing with his Slim Devices (nee Logitech) Squeezebox Classic, I just had to have one. I just wished they had one with speakers- the place I want to put it doesn't have a stereo handy. A quick visit to their website shows the new Squeezebox Boom- perfect! Clickety-click to Amazon, and it's on the way...

Fast-forward to last night, when I "To My Desk"'d it from my EarthClassMail account and ripped the box open in the office to set it up for a late-night coding session. Right out of the box, I was enamored with the build quality- it's got a beautiful black enamel finish with really clean lines, and it feels quite dense for such a small device. Lots of little niceties like the magnetic remote "dent" in the top of the unit and the sleep/snooze button on top in case you want to use it as a hella-spendy clock radio. Plugged it in and had my SqueezeCentral account created and the device on the network within a couple of minutes. I went for the wired connection at the office- didn't even try the wireless, since our office wireless network security doesn't play well with a lot of devices. I didn't set the local server up (that's for home), so I was just playing with the built-in internet services. There's quite a bit of content available for free- even more if you're willing to create accounts and link them up. I was pleased to see the "local radio" option- it shows you all the internet streams of the local radio stations (all my favorites were on there), as well as allowing you to browse around the world right on the device.

I had pretty low expectations for sound quality. The device was kinda spendy ($279), but not enough of a premium over the speaker-less Classic model's $199 price tag to set my expectations very high. Right from the start, I was blown away. This thing sounds great! It has great mid-bass response from a pair of 4" speakers- the low end is "as expected" (eg, not going to rattle the windows out with sub bass-y goodness), but they do provide a sub-out if you're worried about it (I'm not).

I've seen the device UI described as "fiddly", and I'd have to agree- it takes a bit of getting used to, and the navigation isn't terribly friendly unless you know the whole sequence (as well as whatever nagivation the radio service you're using provides too, since they're all different). Things also work a little differently via the remote than using the wheel. It is more or less consistent, though, once you get used to it. My wife had it figured out within a couple of minutes and was having a blast with the "artist search" stations on the Slacker service.

We're both musicians, and yet there's not a lot of music around the house most of the time. Hopefully this thing will make it easier for us to have music around the house wherever and whenever we want.

Recommended!

Trying TrueCrypt full-disk encryption

I've been looking for a way to secure the data and IP on my laptop without a significant sacrifice of performance, reliability, or convenience. I looked into a few different directions:

BitLocker - This actually became an option once I upgraded from Vista Business to Ultimate (had to rebuild my dev laptop after an unfortunate Windows Update problem that MS couldn't solve). However, my laptop doesn't have a TPM, so I'd have to use an external USB key to boot. External key = high on the security scale, low on convenience. Next!

Windows EFS - Convenient, and allows the flexibility to encrypt at the folder level, but is difficult for multi-user access (something I do more of than I'd like). There's also a major performance hit for SQL Server operations. FAIL.

SQL 2008 Transparent Data Encryption - This one was intriguing, but it ultimately sounds like it wouldn't work well for my needs. I'd have to have the same keys used to create the backups, or encrypt AFTER restore of an unencrypted backup. Also, obviously limited to SQL Server, which doesn't cover everything I need. Either way, not going to fly.

TrueCrypt - Free, supports both file-based volume encryption, as well as bare-metal volume encryption. I'd used TrueCrypt before for the former, as well as for non-performance-sensitive stuff where we needed to move large volumes of sensitive data around on removable drives. I couldn't find anyone talking about the real-world performance hit, though. Windows boot volume encryption support is also fairly recent, so that made me a little nervous.

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!

Yay Chase- security is good!

At some point in the not-too-distant past, I noticed that Chase switched their main home page to use HTTPS. In general, it's a marketing site, so who cares? However, the thing that's great about this is that Chase provides a web banking login right on their marketing site's homepage. Even though the old HTTP page posted back to an HTTPS endpoint on submit, it was a major security hole- subject to phishing, DNS poisoning, man-in-the-middle, and who-knows-what-else attacks. They're also using secure cookies, but not httpOnly. Decent, anyway...

As a side note, we've resisted marketing and user requests for this functionality since day one. Marketing has not (to date) been willing to switch their site to HTTPS-only, and we're unwilling to make the security compromise. I think a number of users were taken aback by our response to "but my bank does it, it must be secure!"

Bravo, Chase- hopefully your competition will follow in your footsteps, leading to a slightly more secure financial web for us all.

Chicago hotel fun

Boy, this is starting to smack of last year's vacation from hell (right down to Jenny still being on United's "see agent, you must be a terrorist" check-in watch list). Didn't make it to the game, so we were sulkily watching the Purdue/Oregon game from our hotel room on a brand new LG flat-panel that looked and sounded like a bad 70's TV with rabbit-ears. I don't understand why hotels spend hundreds of thousands of dollars to upgrade to flat-panel HDTVs in every room, then leave 1980's analog cable infrastructure to drive them. Anyway, right at the end of halftime, the fire alarm went off. Great. At least I thought to grab the car keys and my wallet, so we didn't have to sit in the lobby for an hour. We went and grabbed some munchies at Walgreen's (the only place we can drive to- everything around O'Hare is hotels and industrial areas, and we're still pretty much flooded in). When we got back, the fire alarms had finally stopped, so we went back to the room. We were greeted with a smell about like wet dog- the "balcony" door was leaking onto the carpet from all the rain. To boot, Purdue's butt-kickin' lead from the first half had evaporated, now tied at 20-20. Grr.

Hope we can just cut our losses and get out of here on time tomorrow.