Monthly Archives: February 2004

Can you quit and not even know it?

So my wife’s been working out with a personal trainer at the health club we belong to through work. Yesterday, we get a call from the trainer saying that she can’t meet with Andy because we cancelled Andy’s membership with the health club, which is odd because we hadn’t. So I called the health club this morning and they told me that they cancelled my wife’s membership because Microsoft told me that I was cancelling my membership! So I called the Microsoft benefits line and they informed me that they cancelled my health club membership because the HR system says that I’m resigning from Microsoft this Friday!

Is there some memo I didn’t get?

I’m sure that some wires got crossed somewhere between me and Paul Vijijlkj or whoever is quitting on Friday and it’ll all be straightened out in short order. But it’s just another Brazil-esque reminder of how technology can take on a life of it’s own. Glad I figured this out through the health club ahead of time and not when my next paycheck didn’t show up or my cardkey stopped working…

Background compilation, part 1

Roy points to Philip’s complaint that VB still exhibits problems with multi-language solutions that have been around since the VS 2002 beta. Philip’s completely correct, and the explanation of why this bug still hasn’t been fixed even though we’ve known about it since before VS 2002 shipped bears some explanation. Specifically, the problem is with a mistake we made when designing our background compilation system a very long time ago. Since I’ve been asked more than a few times about how background compilation works, this is an excellent chance to delve into that subject. So let me talk about background compilation for a while and then we’ll get back to Philip’s bug.

“Background compilation” is the feature in VB that gives you a complete set of errors as you type. People who move back and forth between VB and C# notice this, but VB-only developers may not realize that other languages such as C# don’t always give you 100% accurate Intellisense and don’t always give you all of the errors that exist in your code. This is because their Intellisense engines are separate, scaled-down compilers that don’t do full compilation in the background. VB, on the other hand, compiles your entire project from start to finish as Visual Studio sits idle, allowing us to immediately populate the task list with completely accurate errors and allowing us to give you completely accurate Intellisense. As Martha would say, it’s a good thing.

However, doing background compilation is a tricky prospect. The problem is that just as soon as you’ve finished compiling the project in the background, the user is likely to do something annoying like edit their code. Once they do that, the application you just finished compiling is now incorrect – it doesn’t reflect the current state of the user’s code anymore. So, the question is: how do you handle that? The brute force way would be to throw away the entire result of the compilation and start over again. However, since Intellisense depends on compilation being mostly complete, this is impractical – given a reasonably large project, you may never get the chance to give Intellisense because by the time you’re almost done recompiling the whole project, the user has had the chance to type in another line of code, thus invaliding all the work you just did. You’ll never catch up.

To deal with this, we implement a concept we call “partial decompilation.” When a user makes an edit, instead of throwing the entire compilation state away, we figure out the smallest amount of stuff we can throw away and then keep everything else. Since most edits don’t actually affect the project as a whole, this means we can usually throw out minimal information and get back to being fully compiled pretty quickly. Here’s how we do it: each file in the project is considered to be in one of the following states at any one time:

  • NoState: We’ve done nothing with the file.
  • Declared: We’ve built symbols for the declarations in the file, but we haven’t bound references to other types yet.
  • Bound: We’ve bound all references to types.
  • Compiled: We’ve emitted IL for all the properties and methods in the file.

When a project is compiled, all the files in the project are brought up to each successive state. (In other words, we have to have gotten all files to Declared before we can bring any file up to Bound, because we need to have symbols for all the declarations in hand before we can bind type references.) When all the files have reached Compiled, then the project is fully compiled.

Now let’s say that a user walks up to a project that’s reached Compiled state and makes an edit to a file. The first thing that we have to do is classify the kind of edit that the user made. (Keep in mind that “an edit” can actually be an extremely complex one if the user chose to cut and paste one block of code over another block of code.) Edits can generally be broken down into two classifications:

  • Method-level edits, i.e. edits that occurs within a method or a property accessor. These are the most common and also the easiest to deal with because a method-level edit can never affect anything outside of the method itself.
  • Declaration-level edits, i.e. edits that occur in the declaration of a type or type member (method, property, field, etc). These are less common and can affect anyone who references them or might reference them anywhere in the project.

When an edit comes through, it’s first classified. If it’s a method-level edit, then the file that the edit took place in is decompiled to Bound. This involves the relatively small work of throwing away all the IL for the properties and methods defined in the file. Then we can just recompile all the methods and we’re back to being fully compiled. Not a lot of work. Say, though, that the edit is a declaration-level edit. Now, we have to do some more work.

Earlier, when we were bringing files up to Bound state, we kept track of all the intra-file dependencies caused by the binding process. So if a file a.vb contained a reference to a class in b.vb, we recorded a dependency from a.vb to b.vb. When we go to decompile a file that’s had a declaration edit, we call into the dependency manager to determine what files depend on the edited file. We then decompile the edited file all the way down to NoState, because we have to rebuild symbols for the file. Then we go through and decompile all the files that depend on the edited file down to Declared, because those files now have to rebind all their name references in case something changed (for example, maybe the class the file depended on got removed). This is a bit more work, but in most cases the number of files being decompiled is limited and we’re still doing a lot less work than doing a full recompile.

This is kind of the high-level overview of how it works – there are lots of little details that I’ve glossed over, and the process is quite a bit more complex than this, but you get the idea. I’m going to stop here for the moment and pick up the thread again in a few days, because there’s a few more pieces of the puzzle that we have to put into place before we get to explaining the bug.

A requiem for easter eggs…

Tom rebuts Jeremy Mazner’s lament for the disappearance of easter eggs. Ultimately, I think most easter eggs are the equivalent of stories about college exploits: they’re only interesting only to the people who were involved and deathly boring to everyone else. Sure, there is the occasionally clever or humorous easter egg, but most serve no purpose to anybody except as a little ego trip.

I say this knowing full well that I wrote several easter eggs for Access before the prohibition on easter eggs went in. I even wrote one that I thought was somewhat clever: a Magic Eight Ball easter egg. The problem was, I left the team and within several versions the Magic Eight Ball had turned into the Crashing Magic Eight Ball.

I don’t think losing easter eggs is a great loss, personally… (Although those Excel guys were always pretty damn impressive.)

Neither a borrower nor a lender be…

Geek Noise pointed to a tirade against the Cult of Performance that brought to mind a criticism that Jet had of my 10 Rules of Performance entry. The points raised are very well taken – it can actually be more damaging to obsess about performance prematurely than to obsess about it too late. The point that I’m arguing for is moderation. For some reason, developers like to live at extremes – either they’re this way or that, never in the middle. Either they never think about performance or they are completely obsessed with it. Instead, I’m arguing that performance should be a part of the development process and the thought process, but not the only consideration. (If it was, most applications would never ship.)

I suppose this is all human nature, if you look at the way that people tend to polarize in other areas. The title for this entry comes from a speech Polonius gives his son Laertes in Hamlet in which he’s purporting to give him some life advice. Since Polonius is sort of a doddering old windbag, most of the speech boils down to useless platitudes along the lines of be smart, but not too smart; be nice, but not too nice; be rich, but not too rich. However, he does end with a good bit of advice that, nontheless, has got to be the most difficult to follow:

This above all: to thine own self be true,
And it must follow, as the night the day,
Thou canst not then be false to any man.

If you think about it, a lot of my performance advice boils down to a variation on this theme. Most of what I argue for is to stop and take the time to understand the true nature of your application and work with that. Obsessing about the performance of code you haven’t even written yet doesn’t fall into that category…

Blogging is like waiting for the bus…

…nothing arrives for a long time and then a bunch of them show up together. (Apologies to Alan Moore for the corrupted quote.)

I was having a nice, leisurely week getting caught up but couldn’t think of anything inspiring to write about to save my life. Then I go and get very ill (ending up briefly in the ER to get rehydrated because it was after hours at the doctor’s offices, happy, happy, joy, joy) and I find lots of interesting things to blog about showing up in my inbox. Feh.

The fever seems to have broken (knock on wood) and some of the other fun aspects of whatever virus I’ve got seem to have passed, but I’m still only partially here. I’ll see if I can catch up some this weekend…

In defense of Krispy Kreme…

I could have written a comment on Raymond’s blog about his dis of Krispy Kreme, but then I thought I’d write a full fledged entry. He says:

I don’t understand the appeal of KK donuts. They have no flavor; it’s just sugar.

…and with that, Raymond proves that he did not grow up in the South. First, it is a maxim of Southern cooking that anything that tastes good with sugar will taste even better with lots more sugar. Case in point: iced tea. Frankly, I don’t know how the rest of the world manages to drink tea without a ton of sugar dumped in it. My mom’s recipe for iced tea? Make about a quart of tea and then dump in 3/4 a cup of sugar. Sure, what you get tastes more like sugar water than tea, but that’s the point. Southerners would pour raw granulated sugar down their throats if their stomachs could handle it… Which, now that I think about it, may explain Krispy Kremes…

Of course, the reality is that my opinions of Krispy Kremes, like Raymond’s opinions of Dunkin Donuts, have been bred in. Growing up in North Carolina, home of Krispy Kreme, I’ve been eating those suckers since I was a kid. Nothing says “home” like Krispy Kreme, which is why the KK stores opening up in the Pacific Northwest have induced a kind of cognitive dissonance every time I drive by them. (It’s also weird to see stores that are so new… I’m more used to stores that are so old my parents went to them as kids. I also think those older machines make better doughnuts, but I could be wrong on that.) Now if we could just get a damn Chick-Fil-A franchise opened up in Seattle, I’d never have to go home to see my parents again!

I will have to admit, though, that Seattlites were totally out of control when the first KK opened in Issaquah. There were, like, hour long lines at 4 in the morning. People would ask me, when they found out I was from a state that already had Krispy Kremes, “are they really that good?” My answer was always: “They’re really good but, hey, they’re still just doughnuts.”

(I will add that my parents are safe – I’ll continue to visit them until Bullock’s Bar B Que starts licensing franchises! Mmmmm…. hush puppies…)