Client.Close()

I know I don't always follow all of the rules when I'm writing my side projects, but a major reason is that people don't stress the value of certain things. For instance, I'm not overkill on commenting every single line. I'm fairly descriptive with my method and variable names and I always add commenting when I do things outside the box. I've never had a problem figuring out what I was doing later... but for that matter, when I debug through other peoples uncommented code I rarely have issue understanding what's going on. Honestly, all I've ever found commenting good for is describing the intent of a chunk of a code... I can always tell what it IS doing simply by looking at it.

But, onto the reason for this post... I've been creating services for ages and I've always noticed the little note from Microsoft when you navigate to the location of the service in the browser to always call the Close operation on the service when you're done. However, people in the office don't even do this and I've never had a problem which I can explicitly blame on having not done this. But I decided to tinker with it in my application and all of a sudden everything is more robust and faster. I haven't hit a single exception from my service in any of the classes I went and tidied this up in the other classes and I must say I'm happy with the results. 

The only complaint I will make is the implementation. I'm not 100% sure what is happening, but if I call it right after an async call there is a delay. I believe it is waiting for the response first, which kind of violates the purpose of an async call. Using lambda statements or delegates it is possible to call it in callback method or I can pass it as the UserState in most calls and when I do it in this fashion there is no perceivable delay. I only noticed this because on some of my grids I trigger an update every single time the selected item changes, when I had the Close() in body of the method calling the async method the selected row took a half second or so to change rows, but when I put it in the callback there is no delay (obviously, because I don't call Close until after the row has changed). The delay is short enough that I would find it hard to prove if there is a delay on the callback.

Anyway... seems weird to me. I'm happy about the performance boost. In general data access and manipulation times have decreased and it is only on a few screens where I don't have the close in the callback where I don't notice the delay if it does happen. But even more important is the integrity of the system seems much better now. That would be worth a decrease in performance to me.