AJ's blog

May 28, 2007

IDisposable – 1, 2, 3, …

Filed under: .NET, .NET Framework, C#, Software Development — ajdotnet @ 4:28 pm

Note: See also the sequel IDisposable Reloaded

recycleIDisposable is one of these beasts. Considered to be common knowledge and yet I regularly encounter code that simply ignores the demand. A well documented pattern and yet I occasionally stumble over improper usage of the pattern. And this is just the beginning; the finer details are lost more often than not.

Calling IDisposable

IDisposable’s sole purpose is to free scarce or expensive resources quickly and cleanly. The usually mentioned examples are files, database connections, and unmanaged resources. Rarely mentioned is the fact that a class becomes an expensive resource by the very fact that it implements IDisposable (and asuming the pattern below is used, including the finalizer. If Dispose() is not called the object will survive one garbage collection, making it to the second generation and live longer than intended, blocking memory and requiring a more thorough GC to get freed.)

Therefore the advice is: If it implements IDisposable, call it. Always!

Basic implementation

Implementing IDisposable is a well documented pattern but it regularly is not observed properly. The gist is:

  1. Implement IDisposable.Dispose() to call a protected virtual method Dispose(bool disposing) with true and deregister the object from finalization (i.e. call GC.SuppressFinalize(this);)
  2. Implement the finalizer to call Dispose(false) as fallback, should the caller forget the call to IDisposable.
  3. Implement Dispose(bool) to free managed resources if disposing is true and to always free unmanaged resources.

public class DisposableObject: IDisposable
{
    ~DisposableObject()
    {
        Dispose(false);
    }
    
    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }
    
    protected virtual void Dispose(bool disposing)
    {
        if (disposing)
        {
            // free managed resources
        }
        
        // free unmanaged resources
    }
}

If you implement IDisposable you have to follow this pattern. Period. And you do implement it if your class manages other resources, e.g. if it holds a file reference or some kind of unmanaged handle.

OK, up to here we’ve covered what I should hope to be common knowledge. But there is more. Not terribly complicated but things to consider anyway.

Advanced patterns

One decision to be made is how the object will behave after disposing it.

  1. It could be revived, e.g. a file could be reopened. In this case it should GC.ReRegisterForFinalize(); to start all over.
  2. The call could be oblivious, i.e. not care at all but also not providing the means to do anything with it (e.g. providing the necessary calls only as c’tors).
  3. It could be unforgiving; in which case it would throw an ObjectDisposedException.

Please note that the following classes build on the above example (i.e. DisposableObject).

Revivable object:

public class RevivableObject : DisposableObject
{
    public RevivableObject()
    {
        // not yet…
        GC.SuppressFinalize(this);
    }
    
    public void Open(/*…*/)
    {
        // open the resource
        
        // and make sure the GC knows about this
        GC.ReRegisterForFinalize(this);
    }
}

Oblivious object: 

public class UseOnlyOnceObject : DisposableObject
{
    public UseOnlyOnceObject(/*…*/)
    {
        // open the resource only via c’tor
    }
    
}

Guarded object: Every method needs to call AssertNotDisposed() as precondition.

public class GuardedObject : DisposableObject
{
    bool _disposed = false;
    
    protected override void Dispose(bool disposing)
    {
        base.Dispose(disposing);
        _disposed = true;
    }
    
    protected void AssertNotDisposed()
    {
        if (_disposed)
            throw new ObjectDisposedException(GetType().FullName);
    }
    
    void Foo()
    {
        // check preconditions
        AssertNotDisposed();
        
        // …
    }
}

Dispose and tell

A fair number of classes do not only dispose themselves, they also tell about it — via a respective event (e.g. the component class.)

public class ObservableObject : DisposableObject
{
    public event EventHandler Disposed;
    
    protected virtual void OnDisposed(EventArgs ea)
    {
        if (Disposed != null)
            Disposed(this, ea);
    }
    
    protected override void Dispose(bool disposing)
    {
        base.Dispose(disposing);
        OnDisposed(EventArgs.Empty);
    }
}

Object graphs

Consider the following use case: You implement some kind of controller pattern for your web pages; the controller manages references to business services. A simple implementation would look like this:

public interface IBusinessService
{
}

public class Controller
{
    Dictionary<string, IBusinessService> _services= new Dictionary<string,IBusinessService>();
    
    public IBusinessService GetBusinessService(string name)
    {
        IBusinessService ret= null;
        _services.TryGetValue(name, out ret);
        if (ret == null)
        {
            ret = CreateBusinessService(name);
            _services[name] = ret;
        }
        return ret;
    }
    
    protected virtual IBusinessService CreateBusinessService(string name)
    {
        // create business service, e.g. using a factory
        return null;
    }
}

public class PageWithController: Page
{
    Controller _controller;
    
    public Controller Controller
    {
        get { return _controller; }
    }
    
    protected override void OnPreInit(EventArgs e)
    {
        _controller = CreateController();
        base.OnPreInit(e);
    }
    
    protected virtual Controller CreateController()
    {
        // create controller , e.g. using a factory
        return new Controller();
    }
    
}

Now, what does that have to do with IDisposable? No disposable object is taking part in this sample, right?
However this implementation lays the infrastructure to be used with derived classes, controllers as well as business services. And those derived classes may very well implement IDisposable, e.g. a business service holding a database reference. Should the implementor of that business service have to build the disposing infrastructure for that service? Or should the infrastructure anticipate that need and already be aware of IDisposable? Take that as rhetorical question and have a look at the corrections:

public class Controller: GuardedObject
{
    // code as above…
    
    protected override void Dispose(bool disposing)
    {
        if (disposing)
        {
            DisposeHelper.DisposeElements(_services.Values);
            _services = null;
        }
        base.Dispose(disposing);
    }
    
}

public class PageWithController: Page
{
    // code as above…
    
    public override void Dispose()
    {
        DisposeHelper.Dispose(_controller);
        _controller = null;
        base.Dispose();
    }
}

I leave the implementation of the DisposeHelper class to your imagination.

So, the advice in this case is: If you for lay some kind of basic infrastructure, anticipate the usage of disposable objects and build an uninterrupted “dispose trail”.

That’s all for now folks,
AJ.NET

kick it on DotNetKicks.com

Advertisements

May 20, 2007

About the Virtue of Not Improving Performance

Filed under: .NET, .NET Framework, ASP.NET, C#, Software Architecture, Software Development — ajdotnet @ 6:11 pm

I am very much in favour of performance awareness, as previous posts should have shown (optimize itcache as cache canperformance is king, …), nobody question that. But I repeatedly stumble over advice that I find … questionable.

So, with this post, I thought I might pick up some of the more common hints and tell you why you should not (have to) apply them for performance reasons. Yes, at the price of processor cycles. Here are some links that contain that advice (not the only ones, though):

Please note that my statements are meant for developers of ordinary line-of-business or web-applications. If you write real time software controlling atomic plants, this article is not for you. (Neither is it for the guys at Microsoft working on the .NET Framework or SQL Server.)

Please also note that I left out things related to garbage collection and finalization on purpose.

Optimization techniques that adversely affect class design

Some optimization techniques address the way the CLR is working and are aiming to help the JIT compiler to produce better (read “faster”) code.

Consider Using the sealed Keyword. The rationale behind this recommendation is “Sealing the virtual methods makes them candidates for inlining and other compiler optimizations.” (msdn)

The only candiates for this advice are derived classes of your application. Declare them as sealed won’t hurt the class design. But won’t the virtual methods usually be called via the base class? No very much to gain then anyway. Then why bother?

Consider the Tradeoffs of Virtual Members? Consider the Benefits of Virtual Members, I’d rather say! “Use virtual members to provide extensibility.” (msdn). One should avoid making a method virtual if it’s not intended to be overwritten. But that’s a question of class design and design for extensibility rather than a performance related one. Avoiding a virtual declaration for performance reasons? No way.

These are just examples, there is other advice, e.g. regarding voilatile or properties. All in all, I personally have dismissed this category of performance related advice. It’s either unnecessary (i.e. should be done for reasons far more important, like “know what you do and design things right”) or of adverse effect (like scarifying good design for small gains of performance).

Optimization techniques that adversely affect code

Some techniques aim at eliminating unnecessary repetitive calls:

  • Avoid Repetitive Field or Property Access
  • Inline procedures, i.e. copy frequently called code into the loop.
  • Use for loops rather than foreach

These … hints… are what I call developer abuse. Wasn’t inlining, loop unrolling and detection of loop invariants one of the better known optimization techniques of C++ compilers? And now I shall do that manually? “Optimizing compiler” is not part of my job description, sorry.

String optimization

My special attention goes to … Mr. String. Mr. String, could you please come up to the stage… Applause for Mr. String!

StringBuilder abuse, i.e. forgetting about +/String.Concat/String.Format, is very common. Take the following code snippet as example:

string t1 = a + b + c + d;
string t2 = e + f;
string t3 = t1 + t2;
return t3;

Quite complex, don’t you think? Wouldn’t you be using a StringBuilder instead? NO! Don’t fall or that StringBuilder babble. I cannot say that all the given advice is wrong; it just plainly forgets to mention String.Concat too often and leads one to a wrong impression.

How many temporary strings do you count? 3? (t1, t2, and t3) Or 5? (a+b put into a temporary, in turn added to c.) Well, the answer is 3, as the c# compiler will translate all appearances of + in one single expression into one call to String.Concat. If you have a straight forward string concatenation use + (but use it in one expression!). If it gets slightly more complex, using String.Format (which uses StringBuilder.AppendFormat internally) might be another option.

Use StringBuilder if you have to accumulate string contents over method calls, iterations, or recursions. Use it if you cannot avoid multiple expressions for your concatenation and to avoid memory shuffling. And please read “Treat StringBuilder as an Accumulator” (msdn) in order not to spoil the effect.

ASP.NET related things

My favourite category 🙂

Disable Session State If You Do Not Use It. That’s sound advice. You may do that for the application. But don’t do it just for one page. If you need session state, chances are you need it for all pages. That particular page is the exception? Well, it can’t be doing very much then and disabling it will hardly improve the performance of your application very much. If you stumble over it go ahead, but don’t waste your time looking for these pages. Spend that time on the majority of your pages that actually need session state; spend it on managing session state efficiently. This way your whole application will profit.

Disable View State If You Do Not Need It. Don’t. You don’t want to do it for the page, as view state is a feature of the controls. You don’t want to do it declaratively for the controls, for that is tedious and error prone work. And you certainly don’t want to do it for every control, for some of them rely in view state to work correctly.
Managing view state is the sensible approach. Find ways to avoid sending large view states back and forth to the client. Check if there is unintended view state usage. The view state is small? Well, why bother? Empty view state is not that expensive. If you worry about that, use derived controls that switch view state off by default.

Using Server.Transfer to avoid the roundtrip caused by Response.Redirect is a bit like penny-wise but pound-foolish. The user requests page A but you decide he should see page B. Rather than letting him know that you just gave him what he did not ask for. If he does a page refresh (not to mention setting a bookmark), you will always get a request for page A and always have to transfer to page B. But rest assured, the last transfer definitely is more efficient than redirecting. Oh, and by the way, you just lied to the user. Telling him he is on the Get_This_Gift_For_Free.aspx page when he actually was on the Buy_Overpriced_Stuff_You_Dont_Need.aspx page. Interesting business model, though.

Use Response.Redirect(…, false) instead of Response.Redirect(… [, true]). Now that’s an example of a half understood issue being made a common recommendation. (Am I becoming polemic? Sorry, could not resist 👿 .)
Redirect throws a ThreadAbortException. “An exception! — Oh my, what can we do about that?” “Oh, don’t worry, we can go through all the data binding, page rending, event handling, and whatever else is left of the page life cycle, we will fight any opponent, such as this perkily grid control that refuses to bind against null. And at the end of the day we will have slain the dragon and it won’t fly again.” OK, now I am being polemic. Anyway. The problem with not throwing the exception should have become clear. If you want to avoid that, try to do it client side.

What to conclude?

Now I’m going to contradict myself: None of the above advice is actually wrong (well, …). Not if you look only on performance in terms of processor cycles. But they are far too expensive in terms of brain cycles and won’t get you the benefit you expect. They trade small gains in performance for adversely affected design, workload on the developers side and additional chances for errors. And they are far too fine grained and restricted to the code level to matter all that much. Usually the interaction patterns between different components or the chosen algorithms have more impact. Not the virtual call to that method, but this non-virtual, non-suspicious method that is called 500 times during one request. Not the fact that 5 strings are concatenated with +, but the fact that those strings result from 10 database calls.

I’m contradicting myself even further: I didn’t say, don’t do it at all. I said don’t do it for performance reasons. There may be other reasons to follow the advice. (E.g. I would “Avoid Repetitive Field or Property Access” in order to have more comprehensible code, code that better supports debugging sessions. “Consider the Tradeoffs of Virtual Members” is no bad advice either.)

If you want to follow some rule upfront, I strongly recommend a sound design and understanding of what you do. And once you’ve got past the broad scenarios, let the profiler tell you what parts of your application to optimize. This way you will spend the work where it matters.

Oh, by the way: Please note that I did not reject every advice. There is a lot of good advice which tells you how to improve performance simply by writing good code (in terms of design, readability, etc.). And quite a few hints for doing things efficiently without adverse effects. Just don’t do it blindly.

That’s all for now folks,
AJ.NET

kick it on DotNetKicks.com

May 12, 2007

Javascript and ASP.NET

Filed under: .NET, .NET Framework, ASP.NET, Software Development — ajdotnet @ 4:03 pm

ASP.NET was never a pure server side framework. Right from Version 1.0 it employed scripts for client side validation. Back then it was meant to…, well set IE users apart, because it worked only as improvement for them. Complementing one’s own server controls with script was the champions league of ASP.NET development — and deployment of these controls was a paint in the… (children around? Sorry!)

Anyway, much is changing in this area. With ASP.NET 2.0 Microsoft has introduced the WebResourceAttribute to adress the deployment problem. (See Creating Custom ASP.NET Server Controls with Embedded JavaScript for a better example.) Ajax is doing away with the browser dependency issues and Microsoft has changed its attitude accordingly, resulting in cross browser capabilities in ASP.NET AJAX.

There is still some work to do to better integrate server side and client side coding model. The ASP.NET AJAX Control Toolkit uses some patterns to better handle scripts (via the RequiredScriptAttribute, though not documented) and to address client side properties and events. Supporting postbacks and server side events is still a little awkward, though.

One thing is for sure: With ASP.NET AJAX Microsoft is taking ASP.NET control development as well as scripting to the next level (if only of complexity). If you’ve coded controls using script before, this is a good thing for you. Or it will render your patterns obsolete, who knows. If you’ve only scratched scripting yet, well, prepare for some work. Javascript is not as easy at is seems and ASP.NET AJAX definitely pushes the limits.

That’s all for now folks,
AJ.NET

kick it on DotNetKicks.com

May 5, 2007

(Framework) Extension Points

Filed under: .NET, .NET Framework, ASP.NET, C#, Software Architecture, Software Development — ajdotnet @ 10:19 pm

The web applications I usually build cannot do without session state. Remember that user choice, get complex parameters to the next page, hold this business object until the user finally says “I’m done, save it”.

Session state on the other hand has a poor interface and a big potential for trouble. I therefore usually use a utility class rather than accessing the Session object directly. Call it SessionData, and it’s implemented as a singleton. SessionData would add serveral features, such as type safe getters/setters; optimizations for default values; checking the serializability of the objects to prevent the serialization problem (I may have mentioned it once or twice); getting some statistics about objects in state (number and size). You get the idea. Fairly generic stuff and a good candidate for the next project.

Then I usally add named properties for the project specific session data. And kiss reusability good bye. 😦

Well, I could use another utility class. Another complementary one? No way.
I could derive from SessionData and use is as replacement. Grand idea. But what about my other generic code that may want to access the session state? How would it know about my derived class?

This is a quite common problem for framework developers. Frameworks need means for the user to change or extend their standard behaviour. This usually includes callbacks, events, and virtual methods. In most cases this relies on the ability to run your own code (e.g. to create your instance or to register your calllback) before the change takes effect. If you have a class that overrides a virtual method, someone has to instantiate your derived class. This someone (or rather the first in line) is usually framework code. Code that needs to know the class it instantiates. Code that has no knowledge of your code. Unless you use a factory.

There are two related patterns that allow a framework to work with user code right from the beginning:

  • Provider pattern: used to register a provider class/object that offers some service (e.g. translation) but that does not necessarily have to exist and does not have a default implementation
  • Class substitution: used to replace standard behaviour with customized versions (e.g. session state handling). If it is not replaced, a default implementation will kick in. 

Please note that the pattern names are (c) by AJ.NET. I made them up, so you may come across different names. The license to use the names is fairly simple: You may use them freely. But if you do I want you to stand up and say “I used this word with permission by AJ.NET.” 😀

Provider pattern

The provider pattern is actually quite simple:

  • Some (singleton) object provides access to the actual provider. It uses the factory to instatiate the concrete implementation and handles the case that no provider implementation exists.

public class TranslationProvider
{
    public static ITranslationProvider Current 
    {
        get
        { 
            // use factory to create the instance
            if (_current == null
                _current= (ITranslationProvider)Factory.Current.Create(„ITranslationProvider“);
            return _current;
        }
    }

<object name=“ITranslationProvider“ type=“AJ.Application.Providers.AppTranslationProvider, AJ.Application.Providers“ />

The calling code can ask for the provider and would do nothing if none is present.

Class substitution

Other than the provider pattern, class substitution needs a fully functional default implementation. However it provides the means to replace this standard implementation with a tailored version.

  • A class provides the default implementation
  • Some (singleton) object provides access to the actual instance. It uses the factory to instantiate the concrete implementation and makes sure the standard implementation is used if no other implementation is available.

public class SessionData
{
    public static SessionData Current
    {
        get
        {
            // use factory to create the instance
            if (_current == null)
                _current = (SessionData)Factory.Current.Create(typeof(SessionData).FullName);
            // fall back to default implementation
            if (_current == null)
                _current = new SessionData();
            return _current;
        }
    }
}

public class AppSessionData : SessionData
{
    public static new AppSessionData Current
    {
        get { return (AppSessionData)SessionData.Current; }
    }
    public Guid CurrentSelection
    {
        get { return base.GetString(“CurrentSelection”, string.Empty); }
        set { base.SetString(“CurrentSelection”, value, string.Empty); }
    }
}

<object name=“AJ.Framework.Providers.SessionData“ type=“AJ.Application.Providers.AppSessionData, AJ.Application.Providers“ />

Now the custom type gets created and can be accessed as AppSessionData.Current. While this class offers type safe access to specific session data it is still guaranteed that the framework code accessing session state will use the very same object to do so. And if AppSessionData changed the behaviour of certain methods (e.g. add traces), user code as well as framework code would participate in this change.

BTW: Did you notice? Even the factory is not called directly, rather it uses the class substitution pattern.

This post concludes this little series about factories. Technically I probably didn’t solve very complex issues. Use a factory, work against interfaces, or in the case of class substitution against a base class. That’s about it. The value that goes beyond a technical approach is realized by the patterns: layer separation, mock object support, interception, and extension.

That’s all for now folks,
AJ.NET

kick it on DotNetKicks.com

Create a free website or blog at WordPress.com.