If you develop web parts for WSS 3.0 or MOSS 2007 long enough, sooner or later you will likely create a web part with more user configurable properties than you care to code. And if you are not careful, your web part will have to carry a hefty payload of embedded markup used to display all of those web part properties in the ToolPart. But have you really thought about how much all of that markup adds to the overall size of your assembly? Probably not. Maybe you should.

While developing our What’s New Web Part we had our regular code reviews to see where code could be trimmed and refactored to keep the assembly size under control. But as you can imagine, with each new feature came some assembly growth. The code reviews trimmed the “low hanging fruit” fat, or so we thought. One of the 5 custom ToolParts in our web part is called Grid Columns…which contains 10 DropDownLists in a vertical arrangement. The point of the ToolPart is to allow a user to select Columns they want to display while the web part is in a grid layout, and each DropDownList contains the list of Columns from which they can choose.

The example below shows the HTML markup necessary to create just 1 instance of the DropDownList.

 

 

Since we are using 10 DropDownLists in this ToolPart, that equates to 180 lines of HTML payload. We moved the option code to a simple function like:

Now granted we just created a function that we will now have to call 160 times to generate 10 DropDownLists, and many will argue that is excessive (among other things). And you want get any arguments from us to the contrary. But it gets worse, the web part also has 4 more ToolParts with another 8 DropDownLists that add yet another 20 calls to the same function every time the web part is placed into Edit mode! However, all things considered we will take the multiple calls to such a function any day. Why? Simple, once we took all of our common (more than 1 instance) HTML controls in all ToolParts, created functions to generate the necessary markup for each control we trimmed just over 15K of fat from the assembly.

Now 15KB isn’t anything to write home about (unless of course the assembly was only 30KB to start with), but let’s consider why you might want such a code refactoring when it comes to your ToolParts. First and foremost ToolPart code is only run when the web part is in Edit mode. Yet the assembly must carry that payload of dormant code at all times. Readability and maintainability…I still hate to look at a bunch of HTML markup in my code…HTML isn’t really “code” anyway is it and it doesn’t belong in our assemblies. And if we really take a moment to consider how often our web parts are actually in Edit mode, isn’t the performance hit by such code refactoring offset by the improved memory footprint of our assemblies?

But don't stop there…think about all of the other recurring HTML used to create a web part ToolPart. As an example, we dropped another 4KB just by calling the following function:

 

Your Name:
Email Address:
	(Optional) Email used only to show Gravatar.
Your Website:
Comment:
Security Code Enter the code shown above in the box below
Add Comment  Cancel