Abstract Classes vs Interfaces: Performance

Recently I was talking to someone about the benefits of Abstract classes vs. Interfaces and performance came up. The theory being that interfaces are slower because it takes more time to loop through the whole object to find the appropriate method. This was an interesting concept to me. I did some searching around and it turns out that this is a common belief. This CodeProject article makes the same argument. I didn’t set out to win an argument or prove a point as I honestly had no idea which would be faster. In fact I can say that I know so little about the lower level implementation of this that I didn’t even know which I would expect to be faster.

I’m no good with simply taking everyone’s word for it, so I wrote up some basic tests. They aren’t perfect for sure but it gets the job done (download the project), and I see some kind of large divergence in the times depending, I’m guessing, on what else my computer is doing at the time. However the overall trend of the results are consistent. Interfaces are faster until you get to an enormous number of iterations. I didn’t see Interfaces show as consistently slower until I was testing in the realm of 100mil or 1bil iterations, they started to become close enough as makes no difference around 10mil iterations.

Even with the divergence I saw, in the typical application I’m not sure this would play a real role. My approach to this will definitely be to not worry about it unless I am A) working on something where optimization is crucial or B) I start to notice some performance issues specifically related to my abstraction. Chances are that if you have performance issues, whether you are using an abstract class or an interface is not the problem. Of course that’s not to say you should ignore known performance issues, but there are enough non-performance related benefits around abstract classes and interfaces that you shouldn’t sacrifice good design or maintainability for an optimization you’re not likely to ever notice in the real world.

The thing I really wonder about now is if it’s a product of the CLR. If I get to it, I may write a similar test in java and post the results.

Unit Tests… ugh!

So I spoke a little about how I’ve become committed to changing the culture on my team. And I’m starting that with an effort in backfilling our app with unit tests. It’s a tremendously large task and to be honest I’m finding it really exhausting, annoying and I’m having a hard time seeing the benefits.

Then I realized that I’m just thinking about unit tests wrong, being too detailed and too broad in each test. This makes them both annoying and complicated to write as well as not really accomplishing their true goal. One of the challenges that I’m having is basically that there’s a big chunk of our application that’s nothing but forms over data. And that gives you, well, not much to test.

We have a three layered design for UI, Business Logic and Data Access. Common stuff. We user Service Location and inversion of control so each service class has a lot of details that goes with it. It’s a pretty small number of places that have detailed business logic. Most of our service layer methods (where I’m focusing my unit tests at the moment) are either pulling data together to display, or updating the data store.

I started off all of my unit tests with complicated checks and ordered assertions to make sure that things are happening in the correct order and beyond that… basically that the right calls are going to the data layer and the right data is being returned. Now I guess I’m coming to the conclusion that I was way over shooting what these need to do and making the tests way too complicated. Seriously, some of these tests were around 40-50 lines long. Preparing all of the data that was going to be passed around. Setting up all of the mocks and all of the expected calls etc. It’s tedious.
Read the rest of this entry »

ReSharper and Friends, No thanks…

There is a group of developers out there who seem to think that tools like ReSharper or CodeRush or a similar tool are a border-line requirement for their jobs. And while I considered linking out to their many, many blogs describing how important it is, I chose against it. Mainly because I don’t want it to seem like I have a problem with them using these types of tools. I just can’t make sense of it.

I installed ReSharper a few months back and I loved it… for 3 days. I was cleaning up code and refactoring all the time but by my fourth day I was back onto a big project and didn’t have time for code cleanup and refactoring. As soon as I switched gears back into development, I started to find resharper irritating. It slowed down my environment. There was always some window it popped up on my screen getting in the way. The Resharper intellisense was consistently placed poorly so it was blocking code I needed to see. It was just in the way; always and forever in the way. I couldn’t take it. I think it was day 5 that I got an email from the Resharper folks asking me to fill out a survey on their product. So I did. Happily.

I blasted it up one side and down the other and then uninstalled it. But then I thought, I liked it for a while, maybe the problem was just that I didn’t like the feel of ReSharper… maybe a different tool with a different interface wouldn’t bother me so much. So I decided to try out CodeRush. I was already sick of things being in the way and my Visual Studio being slowed down. It lasted all of about 3 hours. Sure it did more or less all of the same things as ReSharper, but it was still in my way.

I’m a minimalist all around. I like things simple. In fact, my choice editor is UltraEdit. I find intellisense only mildly useful. The code clean up, sure that’s nice, but only because some people earlier on my project didn’t have the discipline to keep things clean to begin with. The refactoring, honestly wasn’t that much easier than what’s built into VS2010 out of the box so it’s not offering much there, not to mention that I barely use what’s there anyway. Visual Studio has made great progress in 2010 in being lighter, not heavier (hats off to the VS2010 team for that). I don’t want anything that’s a step back in that regard.

At least in the .NET world it seems that guys like me are a minority, I want code, pure and simple. These types of tools don’t keep me as in touch with my code, or with the discipline of writing good code and keeping it clean. My guess is, people who like ReSharper probably love FireFox and have a million plugins. Me? I use Chrome and I have one plugin and that one plugin I use about once a month, if that. I want fast, light and out of the way (if only the UI on Opera were cleaner I’d probably use that…).

The point is, you don’t have to use some crazy collection of Visual Studio plug-ins to be a good coder. More specifically those plug-ins don’t make you a good coder; though they may make it easier for you to be the good coder you already are. Equally, if you’re a bad coder, a tool like this won’t hide it. At best it will probably just make it easier for the rest of your team to tolerate your work. This really applies to anything, I’m a terrible carpenter for instance. Tools won’t hide that. In fact, more elaborate tools just make it easier for me to build something big enough to cause real problems when the truth of my skill is realized.

Using my Service Locator / IoC in IronPython

I’m big on Dependency Injection. I would argue it makes application development easier, faster and more extensible. I realize that sometimes this comes at a cost of a little more challenge in debugging and a performance hit caused by the extra abstraction, but to me it’s an acceptable cost. At least for the type of work I’m doing lately. I’ve written a lot about how I got my configuration files working in the IronPython console and I figured I’d take a second and pass on the very simple but very handy locator module I’ve created to use in IronPython.

We use an Inversion of Control Container (IoC) to accomplish our Dependency Injection. The key thing I suppose to realize, if you’re not familiar with this model, is that access to my full library of classes through IronPython was useless if I couldn’t get my IoC working. The container handles all of the Dependency Injection for me automatically; it’s part of both how my configuration is setup as well as how our IoC works. I’d either need to write a very long and annoying module that injected everything by hand (out of the question!) or get my IoC into IronPython. Once I got the ConfigurationManager Injection working the way I needed, bringing through the IoC was easy.

This is basically the entirety of my locator module. This just loads up the default container which works for a huge majority of the work I need to do. But I could of course request a different container from _loc if I needed it.

import clr
clr.AddReferenceToFile("MyServiceLocator.dll")

import mylib
from MyServiceLocator import *

_loc = MyServiceLocator.GetInstance()
GetInstance = _loc.GetInstance

## Go ahead and load up some of the common services
mymgr1 = _loc.GetInstance[mylib.srvdef.IMyManager1]()
mymgr2 = _loc.GetInstance[mylib.srvdef.IMyManager2]()
mymgr3 = _loc.GetInstance[mylib.srvdef.IMyManager3]()
mywebsrv1 = _loc.GetInstance[mylib.srvdef.Web.IMyWebService1]()

As you can see, accessing a generic is as simple as using [Type] instead of <Type> like you would in C#. I chose to setup mylib as a seperate module that could load up all of the core libraries from our code base that I use on a regular basis. This is a really simple module that I use to namespace things in a more shorthand / “python-y” way. I may at some point turn this into a Python Package to make the namespacing a little clearer. Most of the time (because I use the locator) only need the definition library so it would be nice to be able to only import that.

import clr
clr.AddReferenceToFile("MyServices.dll")
clr.AddReferenceToFile("MyWebServiceGateway.dll")
clr.AddReferenceToFile("MyServiceDef.dll")

import MyServiceDef as srvdef
import MyServices as srvs
import MyWebServiceGateway as websrvs

Read the rest of this entry »

Config Files with IronPython: Overriding the ConfigurationManager

Clarification: This is a need I had in the IronPython console. If you have an IronPython project and run it from a running .NET App I doubt you would need this as the ConfigurationManager knows what your correct AppDomain is.

If you’re like me and have worked in .NET extensively for years, you’re no stranger to config files. You may have even built you’re own set of section handlers to support extra configuration by environment or similar. Since I’ve existed in the neatly wrapped little Microsoft box about how .NET apps should be developed I hadn’t really had issue with the config files overall until today.

I’ve been meaning to dive into Python for a long time but I’ve never made it passed a small script here or there. Recently though I made a decision to invest a little of my time at work in discovering what powers I may unleash. Being a .NET shop it only made sense for me to bring in IronPython so I could continue to leverage the enormous libraries we already had. I quickly made sense of pulling in CLR assemblies and so I started bringing in my own. That was satisfying. It was simple and easy access to manipulating our business objects. Then I wanted to test connecting to the database and so I pulled over an App.config that would (I hoped) load up all the data I needed into the ConfigurationManager.

The design of the ConfigurationManager appears to be making some assumptions that the config file for an executable should be [executable].config (in this case: ipy.exe.config). But for the scope of Python that doesn’t really work. Since any scripts I write will have be running in the ipy context but I may have a number of differently configured scripts. I’ll spare you further details. The point is, since I didn’t want to use an ipy.exe.config file, it wouldn’t work. I tried a number of options for setting the configuration file but nothing worked as needed. Now, I could have written a python module that would have loaded up the needed connections and app settings, etc. But it really didn’t meet my needs as I have extensive custom section handlers and I’m not aware of a way to put that type of config into ConfigurationManager. After some fairly extensive searching, I found a couple of relatively simple solutions not great, but they were effective enough in a .NET app, but not in IronPython. Then I came across this suggestion on StackOverflow that had promise, it didn’t do everything I needed, but the idea was right. So I started exploring that solution and after a lot of hacking around with that I got to a solution that works, at least for my current needs.

The solution is relatively simple, the problem was finding it. I’m am hacking around the framework here and Microsoft doesn’t give up a lot of details about how all of this is working. And there are a lot of internal classes at work that I simply couldn’t get access to without even more hacking around the framework. It required a lot of trial and error and a whole lot of reflection on private variables. That work was really made possible by IronPython. It would have taken me dramatically longer to work through all of these details without the benefit of the interactive shell.

Essentially, I just wrote a new ConfigSystem which gets injected into ConfigurationManager where it is used for all requests from the config file. This isn’t a complete solution. For instance, it doesn’t support sectionGroups in the configSections but it does support the custom config handlers I’m currently using. I have a feeling as soon as I post this, I’m going to find or hear from someone of some really simple way to accomplish this, but oh well.

Read the rest of this entry »