I’ve been spending the last couple of days responding to a customer bug complaining about the performance of the WinForms designer (WFD) when you use C# versus when you use VB. For those who haven’t used it, the WFD uses a round-tripping model where you can visually design your form, have it spit out the corresponding language specific code, edit that code (albeit with many restrictions) and see your changes reflected in the designer.
So why was the experience so much better in VB than in C#? Well, certain parts of the WFD architecture is language neutral (specifically the GUI designer), however both the code-spit and code-analysis portions are implemented by the specific language teams. Now, the code-spit part was no problem whatsoever, but as it turns out the code-analysis portion was a significant hot-spot for C# but not VB.
Now, I’ve talked in the past how C# differs from VB in that they have a full incremental compiler whereas we have a more demand driven model that analyzes and deciphers code as necessary to satisfy the current request being made. We also cache that information but aggressively invalidate that cache to insure that we’re correctly understanding the code that you’re changing. (I’d prefer to have the VB model, but this is how it’s currently done for VS2005 and we have to work within those constraints). Now, for the code analysis portion of the WFD we were doing things very naively (but at the same time very safely). For example, when compiling each statement we were computing a lot of the same information over and over again instead of just using the information we’d compiled for the previous statement and just adding onto it. We were also not caching when we could have. For example in the statements:
When we were trying to bind the identifiers “System”, “Drawing”, and “Color” in the second line we went through the same logic we went through in the first line. So, I updated the code to deal with both issues and we have so far gotten dramatic performance increases from it. However, even though I’ve spent quite a bit of time talking about this, this post is not about the WFD, profiling or the C# implementation. What I actually wanted to talk about was the customer, his problem, and software development in general.
In my last post I talked a bit about driving VS2005 to be shippable and making decisions about what issues need to be addressed, and which issues don’t meet the necessary bar. It could have been quite possible that in the future this bug wouldn’t meet the bar, and it’s altogether possible that the fix I’ve created might not make it because it could be too risky. i.e. we have a working designer right now, and it’s not clear if I might have missed something that will cause functionality to regress with this change, so is the risk of possibly breaking the designer worth the performance gain?
So what does that mean for the customer? He’ll end up with another release where he wants to use C#, but finds the experience decidedly suboptimal. I have no idea when the next version of the product will be, but I’d guess ~2 years after this one. So that means that he’ll have to wait several years in order to get this issue resolved for him. Personally, I’d feel terrible if that happened. This customer has been great to us by providing us with an excellent scenario and performance data that they already collected, and they’ve been incredibly patient so far. Normally i don’t mind deciding not to fix a bug because i feel that it wont’ relaly affect anyone terribly, but in this case i know full well that there is a company out there that would really benefit from this and if we don’t work on this then they will be affected.
Now, consider two different methodologies we could be producing VS in: an incremental model with fast releases every few weeks or months, and an open source model. I think both models would be fantastic for addressing this issue the customer is facing. In the former we’d still have to tell him “sorry, we weren’t able to address this for VS2005. But hey, here’s VS2005.1.” In the latter, the community could provide a patch for this issue that the customer could use. We could then examine the patch and incorporate it into the main source once we’d verified it wasn’t too risky. It still wouldn’t get into the product for everyone until a later release, however, the customer’s problem would be solved and he wouldn’t be left waiting.
I’d really like the VS group to start investigating avenues that allow for this kind of rapid response to customer needs. We’re never going to be able to ship the perfect product, and being able to address issues quickly rather than on a multi-year basis is something I think our customer want and deserve.
What do you think?