I blogged a few days ago about a crazy problem I had with garbage collection in ASP.net under 2.0.  I finally tracked the problem down to Array.Sort.  I created a framework for working with large sets of data in a dynamic way.  This allows us to group data and do other complex statistical things based on fairly open-ended user input, rather than having to write special case code for each scenario.  It uses some reflection to be able to drill into objects.  When sorting, we pass in a dynamic IComparer that can drill into each object and do dynamic comparisons.  Unfortunately, many of our algorithms were dependent on sorting the data first.  This was causing a huge number of allocations due to drilling in and boxing lots of value types.  And, the nature of the sort causes that to happen multiple times per item.

Under 1.1, we took the hit on memory.  It didn't take that long, and it was soon collected.  Under 2.0, the GC seems to recognize this allocation pattern early and proactively begins collecting aggresively.  The problem seems to be that this slows down the sort tremendously, to the point where it essentially comes to a halt.  After a long time, you get a bizarre looking exception about a failed sort from deep in the framework.

What I can't figure out is, during all this time, there's still plenty of memory, and activity on other requests is not impacted horribly.

Well, I took a long hard look at some of the operations, and re-implemented them with a hashing strategy rather than relying on a sort.  As it turns out, for most cases, this is much more efficient.  Long story short, overnight stress testing turned up with clean results this morning.

I've talked about church bulletin humor before. Today, I experienced it first hand. Our church publishes the Wednesday night meal menu in the bulletin. I suppose this is so families can plan around it. I don't think anyone is going to have the church dinner this Wednesday. It read:

Menu: Poopyseed Chicken over rice, vegetable, rolls & dessert.

It was all I could do to keep from falling out of the pew laughing.

This is awesome.  Joe Duffy reveals what I had suspected.  A change to the CLR that will fix the issues I've previously discussed about nullable types in version 2.0!  From his blog:

The core of this change is that the IL box instruction has been modified to recognize Nullable<T>s. For non-Nullables, behavior remains the same; but upon seeing one, it inspects its HasValue property. If HasValue is true, box peeks inside the structure, extracts the T value, and boxes that instead; otherwise, box simply leaves behind a null reference. Obviously, unbox has also been changed to allow nulls to be unboxed back into Nullable<T> structures. This had a rippling effect in the CLR codebase and also required changes to late-bound semantics to mimic the static case.

This is fantastic, and reveals just how strong Microsoft's commitment is to the development community.  I gave my feedback on this before.  I felt it was a problem that aware developers could understand and live with, but I felt that novice developers would struggle with it, and ultimately it would make the feature, and the platform less understandable and approachable.

As you can tell from my earlier post, I had pretty much decided that MS would be unable to fix it at this late stage in the game, and that would be a shame.  But, thanks to some good decision making, they've done it.  Also, the solution was quite similar to my suggestion, I'm happy to say.

Be sure to follow through and read Somasegar's post on the subject.

We're migrating an app to 2.0, and I've come across a rather bizarre behavior.  Basically, after running for a while, the app will begin taking up 100% of one CPU.  Perf counters would indicate that the process is in GC (% Time in GC is very high).

Now, some background.  This is an ASP.net app. We've got very aggresive caching such that the static memory footprint is about 600MB. When things first get going, everyting behaves wonderfully.  Then, at some point, the GC gets hungry or something and starts chewing up cycles.  The heaps never go down.  No allocations are being made.  Nothing tangible seems to be going on.

When requests comes in, they are handled normally, and the GC seems to "get out of the way".  (DB wait time is accompanied by 0% CPU) But after the request is completed, it's back up to 100%.

This app worked fine under 1.1.  And I guess there's an argument that says it still does.  It just doesn't play nice with anything else on the system.  I'm just kind of writing this to get this problem out there in case anyone else is seeing it and is searching for a solution.  I'll probably also ping a few folks at MS to see what they have to say.

[UPDATE] Check out this update.

I finally got around to upgrading the ol' blog. I was just getting too much trackback spam.

Sometime I'll get around to customizing this new theme. I was getting tired of the old one.

A few months ago, I had an entry that showed how to easily get to 32-bit explorer land within 64-bit WindowsXP using Internet Explorer to navigate the file system.  This makes it possible to use 32-bit shell extensions.  In Vista (and possible the IE7 beta on XP), this behavior appears to have changed.  Navigating to the file system simply opens up a new explorer window in the current explorer process rather than loading it within the IE frame.  This is the only gripe I have so far on Vista, and it's probably an IE change, and probably by design.  I'm sure this was changed to reduce the surface area for possible phishing schemes I can think of, but it sure is annoying.

I've seen some possible workarounds on TweakVista and elsewhere, but none that I found satisfactory (I don't want to run the 32-bit explorer as my shell).  So, I may see about throwing together a little app that can host a 32-bit explorer process so I can use my shell extensions like TortioseSVN.

As if I didn't have enough fun stuff to play with, the first Windows Vista beta was released last week.  I put it on my little laptop first, where it ran very well, but I was disappointed that the new visuals didn't run on the crappy video card it has.  So, last night, I put the 64-bit version on my PC, which has a recent ATI card on it.  Everything runs great on it and it's quite beautiful.  Both installs I've done have been utterly trouble free.  It brought back pleasant memories of installing the 95 beta and waiting with anticipation through the "Starting windows for the first time" screen, which always reminded me of that cereal commercial..."taste it again... for the first time".

This evening, I'll be putting my apps back on the PC, so we'll see if I run across any problems there.

Becky's dad came down this weekend and we caught a Round Rock Express game.  It was really fun. I got me a huge hot dog.  We were on the third base foul line, but didn't get any balls near us.  They were playing the team from Colorado Springs.  The "Sky Sox" I believe.  Then, on Saturday, we picked up Becky's mom from the airport and headed to my favorite restaurant, P.F. Chang's.  After taking Becky's dad to the airport Sunday afternoon, Becky, her mom, and I headed to Belton, where we met up with my parents and ate at the new Roadhouse (warning, link plays annoying music) in Temple, where I finally got to pay for some food.

Sorry for the sparse updates.  I've been head-down on quite a few projects recently, so most of my ramblings have taken the form of internal blog entries and emails.  For the last several months, I've been pushing my co-workers to think about migrating to Whidbey (The next version of Microsoft's .Net Framework, the CLR, whatever you want to call it) sooner than later.  Most people know I'm an early adopter of new technology, and always take my suggestions as the ravings of someone infatuated over new things.  However, we're finally moving that direction for one of our biggest tools as a result of some performance optimizations I was able to do with new features provided in 2.0 (namely generics, iterators, and some new asp.net goodness).  The performance opportunities alone are return enough for the investment.

Rico shares with us an overview of these opportunities, and it's a good enough list that even a manager can see the benefits, many of them handed to you without any additional work.