As lived for us every day in Twitter, irc, newsgroups, blog comments, digg, reddit, over and over and over again: vi vs. emacs Microsoft vs. Linux Firefox vs. Chrome Firefox vs. IE Firefox vs. Opera Opera vs. wait, no one cares about…
I guess I assumed that creating a foreign key constraint would automatically create a non-clustered index. I mean, a primary key is a clustered index, why wouldn’t a foreign key also create an index?
A batch process today slowed from completing in about 4 hours to an estimated completion time of around 3 days. Since this was a process that needed to complete daily, well obviously it should complete in less than a day. First order of business was looking at the profiler to see what was going on.
It was exactly one SELECT statement per transaction, no joins, and one predicate in the WHERE clause, on a foreign key. And it took an average of 23 seconds to execute. Yikes.
Next up was checking the execution plan and statistics. This was on a table that doubled in size in one day, to 7 million rows. The culprit naturally was a table scan, and the 230K reads showed why the query took so long. A coworker pointed out that the statistics plan also provided a hint for performance tuning, to add an index.
I really couldn’t believe the foreign key didn’t have an index, but sure enough, it didn’t. Added the index on the foreign key, and the query time was reduced from 23 seconds to nearly instantaneous, 2-3 orders of magnitude better.
And that 4 hour batch process? It finished in about 5 minutes.
Yes, database indexes are your friend. Assuming database indexes are already in place, not your friend.
*sigh*
I’ve hit a bit of a dilemma recently, I want to use features in C# 4.0 and .NET 4.0 to enhance AutoMapper, but this would eliminate the possibility of .NET 3.0 projects from being able to use the new version.
One option is to say that the current version is the last 3.0 version, and if you want 3.0, use that one. Another option is to fork, and keep a 3.0 version going forward, where I can apply bug fixes etc. to it.
This is the first OSS project I’ve been involved in that actually survived to another .NET Framework release, so I’m not entirely sure what the community expectations would be around this area.
My initial thought is just to upgrade the library to VS 2010 and .NET 4, but that might leave a few people in a lurch. Luckily I’m on Git, so it’s not really a problem to support multiple branches.
How have other projects dealt with this?
In 3 easy steps:
My favorite is a namespace rename. Other choices include deleting a core marker interface, renaming a layer supertype class, or changing the folder structure in a project.
Typically, VisualStudio will crash when I do this, though I’m not sure if it’s VS choking or ReSharper. Either way, a large automatic refactoring will cause a crash.
ReSharper likely made it quite a ways through your refactoring before VS crashed. All those unsaved files were likely cached for recovery by VisualStudio, so you can probably get a lot of those changes back. Instead of choosing to revert your local changes, go ahead and recover all those files. It’s key for maximum annoyance.
Since this was an enormous refactoring, maybe affecting hundreds of files, you’ll want to merge your changes back to trunk as soon as possible. After all, you don’t want to be the sucker merging after everyone else has finished their work.
When you’re done, your co-workers will be greeted with one annoying merge, and another fun dialog that never seems to quite go away:
Just when you think you caught the last of the recovered files that had its line endings screwed up, another one pops up. They’ll hate you once because of the core change that affected so many files, making it quite annoying to merge back to trunk. But they’ll form that long-lasting, persistent hate because of this dialog box that keeps coming up. Yes, there is that little checkbox at the bottom, but who reads these things anyway?
This week I made the drive from Austin to Fort Smith and Springdale, Arkansas to speak at the Fort Smith DNUG and the Northwest Arkansas DNUG on UI testing ASP.NET MVC. Although I showed tools such as WatiN and Gallio, I focused more on design for UI testability, and covered items such as:
We stepped through a working, but horribly fragile UI test, and walked through how we can put in a few design techniques to share knowledge between view design and the UI test. Hopefully, my message of “ban test recorders” gets through to someone, as the UI test recorder is something that threw me off for years on creating maintainable UI tests.
You can find the slides and code here:
Testing the last mile in ASP.NET MVC
Thanks to all the guys in Arkansas for the great conversations, and I hope to see everyone soon! One parting shot from a trip to Devil’s Den:
My jeans were soaked up to my knees from that hike…
