Performance, Performance, Performance

As our current version is coming towards the end of its stabilization phase,  I find myself looking at what comes next.   At this time we haven't finalised a Roadmap (in terms of features) for vNext, but we have decided that Performance improvements will be a key component.

I have therefore spent quite a bit of time in the last couple of weeks, profiling our current version (4.3.5).  I have been using a combination of tools,  Red-Gate ANTS Profiler, SQL Server 2005 Profiler, and CacheManager (by Steve Smith on ASPAlliance).

My next few blogs will focus on some of the important bottlenecks I have found, both in memory and speed, and how Module Developers can review their own code to ensure that their modules are not contributing to poor performance.

My first topic is a discussion of the CBO class, and when it should be used, and more importantly when it shouldn't be used.

Let me first describe what the CBO class does.  The CBO (or Custom Business Object) class provides a number of static methods that take a DataReader and converts it into a Business Object.  This is often referred to as "hydration" - the business object is hydrated (or filled). 

As the CBO methods do not know at compile time what kind of object they are "hydrating" they use Reflection.   Reflection is by nature an espensive operation.  It is orders of magnitude slower to create an object using Activator.CreateInstance than to use New.  Equally, PropertyInfo.SetValue is also an extremely expensive operation compared with a simple Property setter in a class.

The TabController, ModuleController and MembershipProvider do not use the CBO class to build their business objects.  They instead have custom "hydrators", such as FillTabInfo, FillModuleInfo etc.  The initial reason for using "custom" hydrators for these classes, rather than the CBO class is that these objects have a deep object structure - CBO only works for simple data types.

Not surprisingly, given the previous discussion, one of the first discoveries I made when profiling the application is that CBO.CreateObject() was one of the top 10 slowest methods, contributing to performance on every request. 

The CBO class is a convenience class, it allows us to use a "generic" methodolgy to hydrate any object, so when we write a Controller class's Get methods we just need to make calls to CBO.FillObject or CBO.FillCollection.  However, this convenience comes at a price, and we need to be aware of this. 

Is the price in performance worth the time it takes to develop a custom hydrator?  In my opinion, I don't think it is worth it.  I spent a few hrs last week writing custom dedicated hydrators for the more common classes, PortalInfo, TabPermissionInfo, ModulePermissionInfo and RoleInfo, and the increase in performance was noticable - CBO.CreateObject is no longer a significant contributor to each request.

As a Module Developer I would recommend that you review your Controller code and for the most common classes build your own custom dedicated hydrators - only rely on CBO for rarely used classes.