Speed up your queries in SQL Server by being declarative

It’s interesting how a lot of the work I’ve been doing lately has in some way involved a kind of performance tuning. Previously I’ve talked about how to increase the performance of .NET applications by using delegates instead of reflection in code that runs frequently.

This time it is all about performance in database processing.

The scenario

Imagine an application that manages a wait list. Users of this application put themselves in line and wait for their turn to gain access to some kind of shared resource. Here are the basic rules of this system:

• The same user can appear in the wait list multiple times, once for every resource she is queuing for.
• The users’ position in the wait list at any given time is decided by a score.
• This score is calculated based on the number of credits each user has in the system compared to the amount required by the resource they wish to access.

Let’s say that this wait list is modeled in a Microsoft SQL Server database with the following schema:

The position of the different users in the wait list is periodically updated by a Stored Procedure that calculates the current score for each and every row in the WaitList table.

So far so good. Now, imagine that this WaitList table contains somewhere around 30 millions rows, and the Stored Procedure that updates all of the scores takes about 9 hours to complete. And now we have problem.

 The imperative SQL approach

Before going into all kinds of general database optimization techniques, let’s start off by looking at how that Stored Procedure is implemented.
Here is a slightly simplified version of it:

CREATE PROCEDURE CalculateWaitListScores_Imperative
AS
BEGIN

DECLARE @rowsToCalculate INT

SELECT @rowsToCalcualte = COUNT(*)
FROM WaitList
AND Score IS NULL

WHILE ( @rowsToCalculate > 0 )
BEGIN

  DECLARE @userID INT
  DECLARE @resourceID INT
  DECLARE @score INT

  SELECT TOP 1 @userID = UserID, @resourceID = ResourceID
  FROM WaitList
  AND Score IS NULL

  -- The actual calculation of the score is omitted for clarity.
  -- Let's just say that it involves a SELECT query that joins
  -- the [WaitList] table with the [User] and [Resource] tables
  -- and applies a formula that associates the values
  -- of the [Credit] columns in each of them.
  -- For the sake of this example we just set it to a constant value
  SET @score = 150

  UPDATE WaitList
  SET Score = @score
  WHERE UserID = @userID
  AND ResourceID = @resourceID
  AND Score IS NULL

  SELECT @rowsToCalcualte = COUNT(*)
  FROM WaitList
  AND Score IS NULL

END

END

If you aren’t into the Transact-SQL language syntax, let me spell out the algorithm for you:

1. Get the number of rows in the WaitList table where the score has never been calculated
2. If there are any such rows, get the user and the resource IDs for the first row in the WaitList table where the score has never been calculated
3. Calculate the score for that user and resource
4. Update the score with the newly calculated value
5. Go to Step 1

In the worst case, this set of operations will be repeated 30 millions times, that is once for every row in the WaitList table. Think about it for a moment.

While looking at this code, I immediately imagined this dialogue taking place between SQL Server and the developer(s) who wrote the Stored Procedure:

Developer: Listen up, SQL Server. I want you to calculate a new score and update all of those 3o millions rows, but do it one row at a time.

SQL Server: That’s easy enough, but I’m pretty sure I can find a faster way to do this, if you’ll let me.

Developer: No, no. I want you to do exactly what I said. That way it’s easier for me to understand what’s going on and debug if any problem occurs.

SQL Server: Alright, you’re the boss.

Jokes aside, the bottom line here is this:

By implementing database operations in an imperative manner, you effectively tie up the hands of the query execution engine, thus preventing it from performing a number of optimizations at runtime in order to speed things up.

And that basically means trading performance and scalability for more fine-grained control.

 The declarative SQL approach

Let’s see if we can make this Stored Procedure run any faster, by changing our approach to the problem altogether.

This time, we’ll tell the database what we want done in a declarative manner, and we’ll let the query execution engine figure out the best way to get the job done.

Here is a rewritten version of the original Stored Procedure:

CREATE PROCEDURE CalculateWaitListScores_Declarative
AS
BEGIN

UPDATE WaitList
SET Score = dbo.CalculateScore(UserID, ResourceID)
WHERE Score IS NULL

END

What we did is basically removing the explicit loop and merging all operations into a single UPDATE statement executed on the WaitList table, which invokes a custom a scalar function (CalculateScore) to calculate the score with the value of the current row.

Now, let’s look at some performance comparison:

That’s a pretty significant leap in speed. How is that possible? A look at the CPU usage on the database server while running the two versions of the Stored Procedure pretty much explains it all:

CPU usage while executing CalculateWaitListScores_Imperative:

CPU usage while executing CalculateWaitListScores_Declarative:

 

As you see, in the first picture the CPU is steadily at 9-10% and is basically using only one out of four available cores. This is because SQL Server is forced to do its work sequentially and has to wait until the score for the current row has been calculated and updated before proceeding to the next.

In the second picture, we are simply telling SQL Server our intent, rather than dictating exactly how it should be done. This allows SQL Server to parallelize the workload than can now be executed on multiple CPU/Cores at once leveraging the full power of the hardware.

Lessons learned

Here are a couple of getaways I learned from this exercise:

1. SQL is a declarative language at its core, designed to work with sets of rows. That’s what it does best and that’s how you should use it.
2. Whenever possible, try to avoid applying an imperative programming mindset when implementing database operations, even if  the constructs available in SQL-derived languages like T-SQL make it easy to do so
3. Don’t be afraid to give up some control over what happens at runtime when your database code runs. Let the database find out the best way to do things, and get ready to experience some great performance improvements.

Hope this helps.

/Enrico

Improving performance with generic delegates in .NET

Lately I have been involved in the performance profiling work of a Windows client application, which customers had lamented to be way too slow for their taste.

The application was originally developed a couple of years ago on top of the .NET Framework 2.0. Its user interface is built using Windows Forms and it retrieves its data from a remote remote server through Web Services using ASMX.

Everything worked just fine from a functionality standpoint. However customers complained over long delays as data was being retrieved from the Web Services and slowly populated the widgets on the screen.
Something had to be done to speed things up.

Reflection is a bottleneck

A look with a .NET profiler tool such as JetBrains DotTrace revealed that a lot of time was spent sorting large collections of objects by the value of one of their properties. This would typically be done before binding them to various list controls in the UI.
The code would typically look like this and was spread out all over the code base:

// Retrieves the entire list of customers from the DAL
List<Customer> customerList = CustomerDAO.GetAll();

// Sorts the list of 'Customer' objects
// by the value of the 'FullName' property
customerList.Sort(new PropertyComparer("FullName"));

// Binds the list to a ComboBox control for display
cmbCustomers.DataSource = customerList;

Apparently line 6 was the one that takes forever to execute. Now, since the sorting algorithm used in the IList.Sort method can’t be changed from outside the class, the weak link here must be the PropertyComparer. But what is it doing? Well, here it is:

using System;
using System.Collections.Generic;
using System.Reflection;

namespace Thoughtology.Samples.Collections
{
    public class PropertyComparer<T> : IComparer<T>
    {
        private string propertyName;

        public PropertyComparer(string propertyName)
        {
            this.propertyName = propertyName;
        }

        public int Compare(T x, T y)
        {
            Type targetType = x.GetType();

            PropertyInfo targetProperty = targetType.GetProperty(propertyName);

            string xValueText = targetProperty.GetValue(x, null).ToString();
            string yValueText = targetProperty.GetValue(y, null).ToString();

            int xValueNumeric = Int32.Parse(xValueText);
            int yValueNumeric = Int32.Parse(yValueText);

            if (xValueNumeric < yValueNumeric)
            {
                return -1;
            }
            else if (xValueNumeric == yValueNumeric)
            {
                return 0;
            }
            else
            {
                return 1;
            }
        }
    }
}

Likely not the prettiest code you have ever seen. However, it’s pretty easy to see what it’s doing:

1. Extracts the value of the specified property from the input objects using reflection.
2. Converts that value to a String.
3. Parses the converted value to an Integer.
4. Compares the numeric values to decide which one is bigger.

That seems like a lot of extra work for a simple value comparison to me.

I’m sure the method was built that way for a reason. This IComparer class is designed to be “generic” and work on any type of value on any object. However my guess is that it won’t work with anything but primitive types (numbers, strings and booleans). In fact the default implementation of the Object.ToString() (used in lines 22-23) method returns the fully qualified name of the class, and that usually doesn’t isn’t much of a sorting criteria in most cases.

The real performance bottleneck here is caused by the use of reflection inside of a method that is called hundreds if not thousands of times from all over the application.

Use delegates instead

At this point it is clear that we need to refactor this class to improve its performance and still retain its original functionality, that is to provide a generic way to compare object by the value of one of their properties.

The key is to find a better way to retrieve the value of a property from any type of object without having to use reflection.

Well, since we do know the type of the objects we are comparing through the generic parameter T, we could let the caller specify which value to compare the objects with by. This can be done by having the caller pass a reference to a method, which would return that value when invoked inside of the Compare method. Let’s try it and see how it works.

Implementing the solution in .NET 2.0

Since the application was on .NET 2.0, we need to define our own delegate type that will allow callers to pass the reference to a method returning the comparable value . Here is the complete implementation of the refactored PropertyComparer class:

using System;
using System.Collections.Generic;

namespace Thoughtology.Samples.Collections
{
    public class PropertyComparer<T> : IComparer<T>
    {
        public delegate IComparable ComparableValue(T arg);

        public PropertyComparer(ComparableValue propertySelector)
        {
            this.PropertySelector = propertySelector;
        }

        public ComparableValue PropertySelector { get; set; }

        public int Compare(T x, T y)
        {
            if (this.PropertySelector == null)
            {
                throw new InvalidOperationException("PropertySelector cannot be null");
            }

            IComparable firstValue = this.PropertySelector(x);
            IComparable secondValue = this.PropertySelector(y);

            return firstValue.CompareTo(secondValue);
        }
    }
}

Our delegate, called ComparableValue, takes an object of the generic type T as input and returns a value to compare that object by.

The comparison itself is than performed by the returned value itself, by invoking the IComparable.CompareTo method on it (see line 27).

All primitive types in .NET implement the IComparable interface. Custom objects can easily be compared in a semantically meaningful way by manually implementing that same interface.

The caller can now invoke the Sort method by specifying the property to compare the items by with an anoymous delegate:

customerList.Sort(new PropertyComparer(delegate(Customer c)
    {
        return c.FullName;
    });

Notice how the property name is no longer passed a a string. Instead it is actually invoked on the object providing compile-time type checking.

Alternative implementation in .NET 3.5

This same solution can be implemented slightly differently in .NET 3.5 by taking advantage of the built in Func<T,TResult> delegate type:

using System;
using System.Collections.Generic;

namespace Thoughtology.Samples.Collections
{
    public class PropertyComparer<T> : IComparer<T>
    {
        public PropertyComparer(Func<T, IComparable> propertySelector)
        {
            this.PropertySelector = propertySelector;
        }

        public Func<T, IComparable> PropertySelector { get; set; }

        public int Compare(T x, T y)
        {
            if (this.PropertySelector == null)
            {
                throw new InvalidOperationException("PropertySelector cannot be null");
            }

            IComparable firstValue = this.PropertySelector(x);
            IComparable secondValue = this.PropertySelector(y);

            return firstValue.CompareTo(secondValue);
        }
    }
}

Great, this saved us exactly one line of code.
Don’t worry, things get much nicer on the caller’s side where the anonymous delegate is substituted by a much more compact lambda expression:

customerList.Sort(new PropertyComparer(c => c.FullName));

The results

Now that we put reflection out of the picture, it is a good time to run a simple test harness to see how the new comparison strategy performs. For this purpose we will sort an increasingly large collection of objects with the two PropertyComparer implementations and compare how long it takes to complete the operation. Here are the results in a graph:

As you see, by using delegates the sorting algorithm stays on the linear O(n). On the other hand with reflection it quickly jumps over in the exponential O(cⁿ) space, where c is the time it takes to make a single comparison.

Lessons learned

This exercise teaches three general guidelines that can be applied when programming in .NET:

• Reflection is expensive. Use it sparingly and avoid it whenever possible in code that is executed very often, such as loops.
• Generic delegates allow to build flexible code in a fast and strongly-typed fashion. This can be achieved by letting callers “inject” custom code into an algorithm by passing a delegate as argument to a method. The code referred to by the delegate will then be executed at the appropriate stage in the algorithm inside the method.
• When reflection is used to dynamically invoke members on a class, the same thing can be achieved by using generic delegates instead, like demonstrated in this article. This technique is widely used by modern isolation frameworks such as Rhino Mocks, Moq and TypeMock Isolator.

Download Sort Test Harness Sample

/Enrico

Building an HTPC

Almost exactly one year ago, I seriously started considering the problem of having the digital content I care about, mostly made up of music and pictures, scattered around different computers.
At home I often found myself thinking “I wish I could watch this movie on the TV instead of sitting in front of a tiny monitor”. At a friend’s house I would sometimes say “I can’t show you the pictures of our last trip right now because they are on my other laptop”.
On top of that I started to have the creepy feeling that that not everything was backed up properly and on a regular basis, since it resided on different machines. This had become both annoying and worrying.

That’s how I got interested in Home Theater PC or HTPC for short.

My goal was to be able collect and organize all of my digital content in the form of music, pictures and movies in one central place, more precisely the living room, and to make it available to other PCs in the house as well as enjoying it on the TV’s big screen.

After looking at a couple of commercial products in that category (particularly Apple Mac mini and Apple TV) I realized the most common thing to do for a geek like me was to go off and build my own HTPC. This way I could pick and choose the hardware parts to build a machine that matches my specific needs.

The requirements

A computer that wishes to rightfully be called an HTPC must have the following basic characteristics:

• Silent
• Low power consumption
• TV connectivity
• Large storage capacity

On top of that, my personal requirements were:

• Be able to play High Definition (HD) movies at high resolution (1080p)
• Be able to play some occasional 3D game
• Do not look like a computer but rather like some Audio-Video piece of equipment

The hardware

Based on these requirements and my budget, I came up with the following hardware configuration:

Motherboard	Gigabyte GA-MA69GM-S2H
CPU	AMD Athlon X2 Dual-Core 4850e 2.5GH
Cooling	Scythe Ninja Mini CPU Cooler
Memory	Kingston DDR2 PC6400 2048MB
Storage	Western Digital 500 GB SATA
Graphics Card	MSI GeForce 8600GT 256MB DDR3
Sound Card	Integrated
Case	Antec Fusion 430 Silver

There are some key points here that lead my decisions I should probably explain.

First of all I decided to go with the cheaper AMD Athlon X2 CPU over an Intel Core 2 Duo, since the performance gain I would get from the Intel processor wasn’t really that important to me to justify the higher price.
Moreover the 4850e uses just 45W of electricity, which contributes in keeping the CPU cool and the power consumption low.

My choice of motherboard was based on a couple of factors:

• The Antec Fusion V2 case (really slick by the way), has only room for a Mini-ATX size motherboard
• It has integrated High Definition Audio sound chip with support for 7.1 channels and DTS (Digital Theater Systems), which basically means great audio for music and movies
• It also has a decent ATI Radeon X1250 graphics chip with HDMI and TV-out ports integrated, which is nice to have in case my graphics card fails

I wanted this computer to be silent, and since I’m not a huge fan of water cooling, I figured the best way to keep the volume down would be to keep as few fans as possible.
For this reason I substituted the stock CPU cooler that comes with the AMD processor with a Scythe Ninja Mini heat sink (shown in the picture below). This would allow me to cool the CPU without needing a fan. Moreover its low profile fits well in the Antec Fusion case.

As a matter of personal preference, the graphics card had to be an NVIDIA GeForce. This particular model not only provides a nice price/performance balance, but is also extremely silent thanks to its fan-less passive cooling through a heat pipe.
The downside is that once installed in the case it takes up the equivalent space of two cards, due to the large heat sink on the backside.

The case was the most important (and expensive) piece of the whole configuration. I have to say the Antect Fusion 430 is a great case for an HTPC.  
As far as aesthetics go, it makes a computer look like a fancy hi-fi amplifier with a shiny aluminum front panel. Moreover it has some nice features like an LCD screen with support for IR remotes and even a volume nod, contributing to the overall experience.

On the inside, it is designed to keep the hardware cool without being loud. It has two big fans positioned on one side of the case blowing cool air from the outside on the CPU and the graphics card, which are the hottest components in the system.

In this picture you can see the two fans on the left side directing the air flow towards the two giants heat sinks mounted on the CPU and GPU.

The software

After the build was done, I immediately installed Windows Vista Home Premium and the required device drivers on it to see how it performed.

Here is how Vista rates the system:

Playing HD movies encoded with the H.264 codec at 1080p on to a 40’’ flat HDTV is no problem at all. I use Cyberlink PowerDVD 9 which supports the NVIDIA PureVideo® feature to offload part of the rendering off to the GPU.

I have to admit I was a little worried that the two fans mounted in the Antec case weren’t enough to keep the system from overheating, especially when HTPC is inside of a closet under the TV.

So I decided to run the excellent Prime95 tool to stress test the system and watch the CPU and GPU temperature with CPU-Z and GPU-Z respectively. The screenshots below show the temperature measured at the two CPU cores when the system is idle (on top) and when running under load (below):

It seems that the passive cooling is doing a pretty good job at keeping the CPU and GPU at low temperatures, even when the system is put under heavy load.

Conclusion

So far I’ve been pretty satisfied with the HTPC I’ve built. It fits well into the living room thanks to its specially designed case and it’s silent enough that I can’t even tell when it’s turned on or off (OK, I can always look at the power led on the front panel). Also it does everything I need it to without issues.

Having a PC working as media center instead of a proprietary custom device such as the Apple TV, definitely is the most flexible choice in terms of what software you can run. It also allows you to tweak the system to your preference, which is a requirement in itself for anyone with a passion for technology.

/Enrico

Isolating WCF through Dependency Injection – Part II

In my previous post, I talked about how to design a class that uses a WCF client proxy in such a way to make it testable in unit tests, without having to spin up a real service to answer the requests.
The technique I illustrated uses a particular Inversion of Control (IoC) principle called Dependency Injection (DI), in which objects that a given class depends on get pushed into it from the outside rather than being created internally.

In this particular case, the external dependency is represented by a WCF client proxy targeting a particular service. This approach enables me to swap the real proxy objects used in production with test doubles while running unit tests, making it possible to assert the class’s behavior in a completely isolated and controlled environment.

Moving from concrete classes to interfaces

Last time we left off with a MailClient class that takes an instance of ChannelFactory<MailServiceClientChannel> in the constructor and uses it internally every time it needs to download Email messages by following three steps:

1. Creating a new proxy instance configured to communicate with the remote MailService service
2. Invoking the GetMessages operation on the service
3. Disposing the proxy

However, as I pointed out before, being the ChannelFactory<TChannel> a concrete class, creating a test double for it isn’t very convenient. A much better approach would be having the MailClient class interact with an interface instead. This way it would be easy to create a fake factory object in unit tests and have the class use that instead of the real one.

After a quick look in the online MSDN Documentation I found that the ChannelFactory<TChannel> class indeed implements the IChannelFactory<TChannel> interface. “Sweet, I can use that!” I thought. But there’s a catch:

The IChannelFactory<TChannel>.CreateChannel factory method requires the caller to pass along an EndpointAddress object, which contains information about where and how to reach the service, like the URI and the Binding.

This isn’t really what I wanted, since it forced the MailClient class to have knowledge of where the remote service is located or at the very least how to obtain that piece of information. This doesn’t really conform to the Dependency Injection principle, since these details naturally belong to the dependent object, and should therefore be handled outside the scope of the class.

The ChannelFactory adapter

The solution I came up with is to create an adapter interface to hide these details from my class. The implementation of this interface would then wrap a properly configured instance of ChannelFactory<TChannel> and delegate all the calls it receives to it.

Here is the definition of the adapter interface:

using System.ServiceModel;

public interface IClientChannelFactory<TChannel>
    where TChannel : IClientChannel
{
    void Open(); 

    void Close(); 

    void Abort(); 

    TChannel CreateChannel();
}

And here is the default implementation:

using System;
using System.ServiceModel; 

public class ClientChannelFactory<TChannel> : IClientChannelFactory<TChannel>
    where TChannel : IClientChannel
{
    private ChannelFactory<TChannel> factory; 

    public ClientChannelFactory(string endpointConfigurationName)
    {
        this.factory = new ChannelFactory<TChannel>(endpointConfigurationName);
    } 

    public void Open()
    {
        this.factory.Open();
    } 

    public void Close()
    {
        this.factory.Close();
    } 

    public void Abort()
    {
        this.factory.Abort();
    } 

    public TChannel CreateChannel()
    {
        return this.factory.CreateChannel();
    }
}

As you can see by using generics we are able to create an implementation that works for different types of proxies.

Notice also that the class requires the callers to specify the name of the configuration element used to describe the service endpoint in the constructor. This way the MailClient class  is completely isolated from having to know about WCF configuration details, and can instead concentrate on its core responsibility, that is to invoke operations on the service and work with the results.

Here is the final MailClient implementation:

public class MailClient
{
    private IClientChannelFactory<IMailServiceClientChannel> proxyFactory; 

    public MailClient(IClientChannelFactory<IMailServiceClientChannel> proxyFactory)
    {
        this.proxyFactory = proxyFactory;
    } 

    public EmailMessage[] DownloadMessages(string smtpAddress)
    {
        // Validate the specified Email address 

        IMailServiceClientChannel proxy; 

        try
        {
            proxy = proxyFactory.CreateChannel(); 

            Mailbox request = new Mailbox(smtpAddress);
            EmailMessage[] response = proxy.GetMessages(request) 

            // Do some processing on the results 

            proxy.Close(); 

            return response;
        }
        catch(Exception e)
        {
            proxy.Abort(); 

            throw new MailClientException(&quot;Failed to download Email messages&quot;, e);
        }
    }
}

The only modification is in the type of the argument declared in the constructor, which is now an interface.

Finally unit testing

We are now able to test our class in isolation by creating fake objects that implement the IClientChannelFactory and IMailServiceClientChannel interfaces respectively, and inject them into our object under test.

In this particular example I am using Rhino Mocks as an isolation framework to create and manage test doubles, but I could as well used just about any other isolation framework out there, such as Typemock Isolator, with the same result.

using Microsoft.VisualStudio.TestTools.UnitTesting;
using Rhino.Mocks; 

[TestClass]
public class MailClientTest
{
    [TestMethod]
    public void DownloadMessages_WithValidEmailAddress_ReturnsOneMessage()
    {
        // Fakes out the WCF proxy
        var stubProxy = MockRepository.CreateStub<IMailServiceClientChannel>(); 

        // Stubs the service operation invoked by the class under test
        stubProxy
            .Stub(m => m.GetMessages(Arg<string>.Is.Anything))
            .Returns(new EmailMessage[0]);

        // Fakes out the WCF proxy factory
        var stubProxyFactory = MockRepository.CreateStub<IClientChannelFactory<IMailServiceClientChannel>>();

        // Stubs the factory method to return the mocked proxy
        stubProxyFactory
            .Stub(s => s.CreateChannel())
            .Return(stubProxy);

        var testObject = new MailClient(stubProxyFactory); 

        EmailMessage[] results = testObject.DownloadMessages("test@test.com"); 

        Assert.AreEqual(0, results.Length, "The method was not supposed to return any results");
    }
}

This concludes this short series of posts on how to apply Dependency Injection to classes that consume WCF services in order to easily test them in isolation with unit tests. I hope this helps.

/Enrico

Isolating WCF through Dependency Injection – Part I

I have to admit that in the beginning I didn’t think Inversion of Control (IoC) Containers were that big of a deal. The idea of relying on an external agent to manage all the associations between objects in an application, sounded like it would bring more problems than advantages. Overkill. But I was wrong.

Since I began using IoC containers in my projects, I found that it naturally leads to loosely-coupled structures in the software. 
This is due to two key design principles that an IoC container will enforce you to follow:

• Classes must explicitly state their dependencies with other classes as part of their public interface.
• Classes never interact with each other directly, but only through interfaces that describe a set of capabilities in an abstract manner.

This decoupling contributes in making the software easily testable and ready for evolution.

Giving up control of WCF clients

In my last project I was designing classes that would need to interact with different Web Services through WCF client proxies.
I needed to test those classes in isolation in my unit tests, without having to have my WCF service host process running in the background, so I figured I would let an instance of a WCF proxy be pushed from outside the classes through an interface, as a dependency, instead of creating it internally, like I would normally do.

This idea fits well with the way tools like svcutil and Visual Studio 2008 work when generating WCF client proxies, since they create a class as well as interfaces exposing the operations that can be invoked through the proxy.

So here is my first implementation:

public class MailClient
{
    private IMailServiceClientChannel proxy;

    public MailClient(IMailServiceClientChannel proxy)
    {
        this.proxy = proxy;
    }

    public EmailMessage[] DownloadMessages(string smtpAddress)
    {
        // Validate the specified Email address

        Mailbox request = new Mailbox(smtpAddress);
        EmailMessage[] response = proxy.GetMessages(request)

        // Do some processing on the results

        return response;
    }
}

Here I am using the IMailServiceClientChannel interface that is automatically generated by Visual Studio when adding a service proxy with the Add Service Reference dialog. This interface contains the signatures of all the operations that are part of the service contract, as well as WCF-specific infrastructure methods to manage the proxy, like Open and Close.

Something is missing

This didn’t feel quite right. I was not treating the WCF proxy like I should since I was not closing it properly after being done with it, and not having any sort of error handling code.

However, at a second thought, I realized this wasn’t really the responsibility of my class. Since I wasn’t creating the proxy instance myself but was instead receiving from the outside, I couldn’t really dispose it inside my method, because it could still be needed by the caller. So here is an alternative implementation:

public class MailClient
{
    private ChannelFactory<IMailServiceClientChannel> proxyFactory;

    public MailClient(ChannelFactory<IMailServiceClientChannel> proxyFactory)
    {
        this.proxyFactory = proxyFactory;
    }

    public EmailMessage[] DownloadMessages(string smtpAddress)
    {
        // Validate the specified Email address

        IMailServiceClientChannel proxy;

        try
        {
            proxy = proxyFactory.CreateChannel();

            Mailbox request = new Mailbox(smtpAddress);
            EmailMessage[] response = proxy.GetMessages(request)

            // Do some processing on the results

            proxy.Close();

            return response;
        }
        catch(Exception e)
        {
            proxy.Abort();

            throw new MailClientException("Failed to download Email messages", e);
        }
    }
}

This time instead of using a proxy instance, the class receives a ChannelFactory instance as an external dependency through the constructor.

Channel factories in WCF are the facilities used to create the pipelines, through which incoming and outgoing messages pass before being dispatched to the receiver or sent out over the wire.

This approach allows me to create a new proxy instances by invoking the ChannelFactory.CreateChannel method ad-hoc inside the class and to properly dispose them as soon as I no longer need them.

According to sources inside the WCF team at Microsoft, it is a best practice to create proxies by reusing the same ChannelFactory object, instead of creating a new proxy objects from the class generated by Visual Studio, since the cost of initializing the factory is paid only once.

This turns out to be a much better approach to assign WCF proxies to classes through Dependency Injection (DI) because now I can create instances of the MailClient class using my IoC of choice, which happens to be Microsoft Unity, with a couple of lines of code:

// Registers the ChannelFactory class with Unity
// and specifies the name of the endpoint to use
// as stated in the configuration file
var container = new UnityContainer();
container
    .RegisterType<ChannelFactory<IMailServiceClientChannel>>()
        .Configure<InjectedMembers>()
            .ConfigureInjectionFor<ChannelFactory<IMailServiceClientChannel>>(new InjectionConstructor("localMailServiceEndpoint"));

var client = container.Resolve<MailClient>();

// The object has now its dependencies already setup
// and is ready to be used
client.DownloadMessages("enrico@somedomain.com");

Here I’m registering the ChannelFactory class with the IoC container, telling it to pass the string “localMailServiceEndpoint” in the constructor whenever a new instance is created.
The ChannelFactory will use that value to look up in the configuration file the URL where the service is located and the protocol it should use to communicate with it, like in this sample WCF configuration:

<configuration>
    <system.serviceModel>
        <client>
            <endpoint
                name="localMailServiceEndpoint"
                address="http://localhost/mailservice"
                binding="wsHttpBinding"
                contract="IMailServiceClient" />
        </client>
    </system.serviceModel>
</configuration>

With this information in place, I’m now able to ask the container to construct an instance of the MailClient class, and it will automatically resolve the dependency on the WCF ChannelFactory for me.

What about testability?

Well, the ChannelFactory is a concrete class and, although certanly possible, can’t easily be faked out (through mocks or stubs) by using one of the common mocking isolation frameworks available out there, since it requires the presence of a configuration file with the proper WCF-specific settings in order to work correctly. This makes the MailClient class still hard to test in isolation.

In my next post I will explain a way to modify this sample to be able to write unit test for classes that use WCF proxies.

/Enrico

Another Visual Studio Color Theme

An interesting trend has emerged in the .NET community during the past couple of years, which involves developers sharing their favorite color theme for the Visual Studio code editor with their peers.

It seems the origin of this trend is somehow related to the introduction of a new feature in Visual Studio 2005 that makes it really easy to export/import all or a subset of the customizations made to the IDE’s into a single XML file. These settings files (*.vssettings) include  every configurable aspect of Visual Studio, from font colors and window sizes to keyboard shortcuts.
Useful for backups as well as for keeping Visual Studio the way you like it every time you switch to work on a different computer.

What developers are most excited about, however, is exchanging the color combinations they use for the text editor included in the IDE, referred to as “themes”.

It’s interesting to notice how a fair amount of developers seem to prefer light text on a dark background, as opposed to the traditional “black on white” paper metaphor  introduced by the word processors. These themes mimic the colors used by the classic programmer text editors of the past, like VIM and EMACS running on DOS or UNIX, which used to sport dark gray or bright blue backgrounds.

Colors are entirely a matter of personal taste, and in this regard I prefer the clean contrast of  white text on black background.
Some people even argue that dark backgrounds are easier on the eyes than white ones, due to the reduced amount of bright light emitted by the computer screens. However I don’t know of any official study conducted to scientifically prove this statement.

Being a developer myself, I also tweaked my own color theme for the text editor I use to write code on a daily basis, which in my case is Microsoft Visual Studio 2008.
I took inspiration from other themes I’ve seen around on the Internet and adjusted them to my taste. In the end, I settled for the following:

• Font: Consolas (the best-looking monospaced font when using ClearType)
• Font size: 11 pt
• Background: Black (#000000)
• Text: White (#FFFFFF)
• Keywords: Light Blue (#4B96FF)
• Classes: Orange (#E4732B)
• Interfaces: Yellow (#E5CA32)
• Value types/Enumerations: Pink (#CA95FF)
• Numbers: Green (#559762)
• Strings: Red (#E83123)
• Comments: Dark Grey (#696969)

It’s a high contrast scheme, but I feel comfortable with it since the colors are not as sharp as other similar ones like John Lam’s Vibrant Ink.

Here is how a C# file looks like with it:

And here is how an XML file looks like:

You can download my Visual Studio color theme here. I have used it for quite a while now and I am pretty satisfied with it. However, I fell I’ll probably tweak it some more in the future. After all, there is always room for improvements.

Download Thoughtology Visual Studio Dark Theme

/Enrico

Enforcing coding standards with Microsoft StyleCop

I can’t stress enough the importance of having a code convention in place before starting in any kind of software project.

What’s a code convention?

A code convention it’s about a team of developers agreeing on a standard way to statically structure the code that will be part of the system they are building together . Note that it doesn’t cover any aspect of the software design, (coupling, cohesion, dependency management and so on) but rather focuses exclusively on how the body of the code is organized.

You may wonder, how is this valuable? Well, a convention has one primary goal that goes beyond plain esthetic: to improve the code readability by achieving consistency. Following a common standard will make it easier for the members of a team to work on each other’s code without the burden of having to mentally adjust to different coding styles.

Style matters

A code convention apply to all kinds of programming elements such as declarations, expressions and statements and it usually covers different aspects. Here is a non-exclusive list of what could be described in a coding standard:

• Naming (casing, use of prefixes/suffixes)
• Ordering (where different members are defined in the context of a class)
• Comments (where they should be placed and how they should be formatted)
• Spacing (between various syntactic elements such as punctuation)

Now, making a group of developers agree on how they should format their code on such a level of detail isn’t the easiest thing in the world. We all see programming code as a way of express our minds, and that includes also how many spaces there are between the parenthesis in a method call and the list of arguments.

Verbal agreement is not enough

Even if you do succeed in finding a middle ground that makes everybody happy (or sort of), you still need to make sure that the team will stick to what has been agreed on, without relying on tedious manual code review. Luckily there are tools out there that can automatically check code against a predefined coding convention.

One of them is StyleCop, a tool internally used by many teams at Microsoft, which has been repackaged and made freely available to the public under the Shared Source license.

The package contains a set of code format rules and a command-line program that checks all the source code files in a Visual Studio project against them and provides a compliance report.
The rules that are included out-of-the-box are the lowest common denominator among different verbally defined coding standard used by many teams at Microsoft who are developing on the .NET platform using C#.

Here is a brief overview of StyleCop’s features:

• Can only check C# code (support for other languages may be added in the future)
• It integrates with Visual Studio and MSBuild, which makes it possible to run validations on demand from the IDE or as part of a build.
• The set of rules to include can be controlled with a configuration file
• Includes a graphic configuration editor (called StyleCopSettingsEditor)
• It offers an SDK that allows to extend it by adding custom rules written as .NET classes 

As mentioned, StyleCop includes a Visual Studio add-on, which allows to run it at any point in time against the currently opened project from a menu item.

By default the results of the validation are reported back to the user as warnings, but you have the option to have them show up as errors, if you care enough about consistency that is.

Configuration can be controlled via a Settings.StyleCop file, which is easily edited with the accompanying GUI editor.

StyleCop can also be run through a set of MSBuild tasks. All you have to do is include the target file that invoke the proper tasks in your custom build definition or Visual Studio project file:

<Import
Project="C:\Program Files\MSBuild\Microsoft\StyleCop\v4.3\Microsoft.StyleCop.targets" />

Resources

You can download the latest version of StyleCop from MSDN including documentation and samples. If you need more information, here you can find a good tutorial on how to successfully integrate StyleCop in your .NET project.

/Enrico

GDI memory leak in Windows Forms

A while ago I run into a rather interesting and insidious bug, which I thought I would share.

The scenario

We had a desktop application developed on the .NET Framework 2.0 using Windows Forms. Part of the requirements for this application was that the standard Windows controls had to be modified to have a custom appearance, to suite the customer’s needs. Since classes that are part of Windows Forms are really nothing more than thin managed wrappers around Windows’ graphic subsystem GDI, many customizations that required  the use of functions not directly exposed through .NET, forced us to invoke the Win32 API directly.

Now, for someone who has been developing on a virtual machine for a long time (whether it be the CLR or Java), commodities like garbage collection are quickly taken for granted. And when the time comes to step out of the safe and cozy managed world, it is easy to forget that those assumptions are no longer valid. And that’s where problems usually start.

As a side note, if we were to build the same application today we would definitely choose Windows Presentation Foundation (WPF) over Windows Forms as UI technology,  since WPF allows to easily define the controls’ visual layout separately from their functionality without leaving the CLR.

The bug

Back to our case. Our Windows Forms application would run fine under normal operations, for about 3 hours until it suddenly crashed reporting a System.OutOfMemoryException (OOM). We also noticed that the application would survive for a shorter period of time if it was used more “intensively” (meaning opening and closing a lot of forms).

By looking at the log files we could determine that the exception was always originated from the constructor of a Bitmap object, which lead us to think that we were looking at a memory leak of some sort of unmanaged graphic resources.
Like everything else in the System.Drawing and System.Windows.Forms namespaces, also the Bitmap class holds a reference to a corresponding GDI object, which is a resource allocated outside of the CLR and as such it must explicitly be released when no longer in use.
Oddly enough, a through examination of the source code confirmed that all bitmap objects were correctly released from memory by calling the Dispose method on them. So what was leaking?

To further investigate exactly what was being used and left hanging around, we used a free tool called GDIUsage, which shows exactly how many and which kinds of GDI objects are being allocated by an application. On the left picture you can see how memory looked like at application startup compared to after a couple of minutes of normal usage.

 

It was apparent that we were creating an awful lot of font objects and forgetting to delete them! But why would it take a long time for the application to crash? Were we hitting some kind of threshold?

It turned out Windows puts a limit on the number of total GDI objects that can be created inside of a process. And that limit is exactly of 10.000 GDI objects in Windows XP. This means that  allocating GDI object number 10.001 will always cause an error. You can use Task Manager to see how many GDI resources each process has currently allocated by selecting the GDI Objects column.

The solution

At this point it was a matter of tracking down where in the source code we were creating System.Drawing.Font objects. Considering the rate of growth of these fonts instinct suggested it ought to be in some kind of global function that was being called from different places in the application. Here is what we found:

[DllImport("gdi32.dll")]
private static extern IntPtr SelectObject(IntPtr hDC, IntPtr hObject);

[DllImport("gdi32.dll")]
private static extern bool DeleteObject(IntPtr hObject);

[DllImport("gdi32.dll", EntryPoint = "GetTextExtentPoint32A")]
private static extern bool GetTextExtentPoint32(
IntPtr hDC, string lpString, int cbString, ref SIZE lpSize);

[StructLayout(LayoutKind.Sequential)]
private struct SIZE
{
    int cx;
    int cy;
}

/// <summary>
/// Gets the width and height of a string with the specified font.
/// </summary>
/// <param name="g">The graphic context to measure the string.</param>
/// <param name="text">The string to be measured.</param>
/// <param name="font">The font used to display the string.</param>
/// <returns>The size of the string in width and height.</returns>
public static SizeF MeasureString(Graphics g, string text, Font font)
{
    SIZE sz = new SIZE();
    IntPtr hdc = g.GetHdc();
    IntPtr prevFont = SelectObject(hdc, font.ToHfont());

    GetTextExtentPoint32(hdc, text, text.Length, ref sz);

    DeleteObject(SelectObject(hdc, font.ToHfont()));
    g.ReleaseHdc(hdc);

    return new SizeF((float)sz.cx, (float)sz.cy);
}

Sure enough the MeauseString method was being called from all over the application (don’t ask why). Do you notice anything particularly odd in the code? Let me show you the offending line:

// The Font.ToHFont() method creates a new Font GDI object
// whose reference is being passed as argument
// to the SelectObject Win32 function
// but is never explicitly deleted
IntPtr prevFont = SelectObject(hdc, font.ToHfont());

And here is how we fixed it:

public static SizeF MeasureString(Graphics g, string text, Font font)
{
    IntPtr hdc = IntPtr.Zero;
    IntPtr f = IntPtr.Zero;
    IntPtr prevFont = IntPtr.Zero;
    SIZE sz;

    try
    {
        sz = new SIZE();
        hdc = g.GetHdc();
        f = font.ToHfont();
        prevFont = SelectObject(hdc, f);
        GetTextExtentPoint32(hdc, text, text.Length, ref sz);
    }
    finally
    {
        DeleteObject(f);
        DeleteObject(prevFont);
        g.ReleaseHdc(hdc);
    }

    return new SizeF((float)sz.cx, (float)sz.cy);
}

As you can see we made sure the DeleteObject Win32 function is called to release the Font object created by the Font.ToHFont() method.

Lessons learned

So, what did we learn from this experience? We can summarize it in 3 rules of thumb when dealing with unmanaged code in .NET, whether it be Win32, COM, you name it:

• Pay attention if any of unmanaged functions you are calling goes out and creates a new instance of some resource in memory. Carefully reading the specific API documentation is vital.
• Every time you allocate memory it is your responsibility to explicitly free it when it is no longer needed by the program. No Garbage Collector will do this for you, you are on your own.
• When creating a new unmanaged object, save a reference to it in a variable that you can use to reach that same object at a later time and remove it from memory. If you lose the reference before the object is explicitly destroyed, you have no way to reach that memory and it leaks.

I hope this rules will help you avoid some of the most common pitfalls leading to memory leaks in your own applications.

/Enrico

Managing shared cookies in WCF

Managing state across the HTTP protocol has always been one of the major challenges faced by developers when building applications on the web. Of course web services are no exception.

One way to overcome the stateless nature of HTTP without putting to much load on the web server, is to offload some of the information that has to be saved in the context of a particular conversation over to the client. The HTTP specification provides a native mechanism to do just that, by allowing web servers to bundle small pieces of textual data in a dedicated header of the response messages sent to the clients. These recognize the special payload, extract it, and store it in a local cache on disk to have it ready to be sent with every subsequent request. These small texts are technically known as “cookies”.

Cookies are opaque in ASMX

Cookies go back a long time in the history of HTTP, and have served the Internet (fairly) well so far. Sure they brought some serious security issues with them, but for the most part they have been a conventient way for developers of web sites/web  applications to save temporary pieces of information off the server and have it transparently sent back by the client with each request.
This guarantee comes from the fact that every web browser on Earth has had the notion of cookies since web browser have had built-in support for cookies for the last 15 years or so.    

However, when it comes to web services, this assumption is no longer valid, since the client isn’t necessarily a web browser and doesn’t have to know how to handle cookies.

In the ASMX programming model, this problem has a quite simple solution. The client objects used to invoke operations on a web service can optionally reference an instance of a “cookie container”, were all cookies passed back by the web server are automatically stored and sent with each request.

using System.Net;

public class Program
{
  private static void Main(string[] args)
  {
    // Creates a new instance of a client proxy for an ASMX Web service
    MyWebServiceClient client = new MyWebServiceClient();

    // Creates the cookie container and assigns it to the proxy
    CookieContainer cookieJar = new CookieContainer();
    client.CookieContainer = cookieJar;

    // From now on cookies returned by any of the web service operations
    // are automatically handled by the proxy
    client.DoSomething();
  }
}

The advantage with this approach is that it is fairly opaque to the developer, which can inspect the contents of the cookie container at any time. As a bonus, it allows the same cookie container to easily be shared between multiple clients, enabling the scenarios when same cookie is required by multiple web services.

But they are transparent in WCF

In the WCF world, things are a little bit different. WCF, being a transport-agnostic technology, doesn’t allow the concept of a cookie to be directly reflected in the high level API, since it is specific to the HTTP protocol. This translate in practice in the web service client objects not having any CookieContainer property to set and retrieve.

However this isn’t necessarily a problem, since Microsoft did put a the possibility to enable automatic “behind the scenes” cookie management for HTTP clients. This of course is implemented at the WCF binding level, and can be switched on with a configuration setting:

<system.ServiceModel>
    <bindings>
        <basicHttpBinding allowCookies="true">
    </bindings>
    <client>
        <endpoint address="http://localhost/myservice"
                  binding="basicHttpBinding"
                  contract="IMyService" />
    </client>
</system.ServiceModel>

When this option is enabled the client will make sure all cookies received from a given web service are stored and properly sent on each subsequent request in a transparent fashion. But there is a catch: the cookie is only handled in the conversation with one web service. What if you need to send the same cookies to different web services?

Well, you’ll have to explicitly set the EnableCookies setting to false  (kind of counter-intuitive I know, but required nonetheless) and start managing the cookies yourself. Luckily, there are a couple of solutions.

Ad-hoc cookie management

If you wish to manually retrieve, store and send a the same given set of cookies from two different web service client objects in WCF, you could do this ad-hoc this way:

using System.ServiceModel;
using System.ServiceModel.Channels;

public class Program
{
    private static void Main(object[] args)
    {
        string sharedCookie;

        MyWebServiceClient client = new MyWebServiceClient();

        using (new OperationContextScope(client.InnerChannel))
        {
            client.DoSomething();

            // Extract the cookie embedded in the received web service response
            // and stores it locally
            HttpResponseMessageProperty response = (HttpResponseMessageProperty)
            OperationContext.Current.IncomingMessageProperties[
                HttpResponseMessageProperty.Name];
            sharedCookie = response.Headers["Set-Cookie"];
        }

        MyOtherWebServiceClient otherClient = new MyOtherWebServiceClient();

        using (new OperationContextScope(otherClient.InnerChannel))
        {
            // Embeds the extracted cookie in the next web service request
            // Note that we manually have to create the request object since
            // since it doesn't exist yet at this stage 
            HttpRequestMessageProperty request = new HttpRequestMessageProperty();
            request.Headers["Cookie"] = sharedCookie;
            OperationContext.Current.OutgoingMessageProperties[
                HttpRequestMessageProperty.Name] = request;

            otherClient.DoSomethingElse();
        }
    }
}

 

Here we are interacting directly with the HTTP messages exchanged with the web services, reading and writing the cookies as a string in appropriate headers. In order to accomplish the task we need to use the “transport-agnostic” WCF API, which indeed makes the code more verbose compared with the ASMX example.

Centralized cookie management

In situations were cookies must be managed in the same way for all web services invoked from a client applications, your best bet is to opt for a centralized solution by applying a very useful feature in WCF: message inspectors.

Message inspectors provide a hook in the WCF messaging pipeline offering the chance to look at and possibly modify all incoming or outgoing messages that transit on the server-side as well as on the client-side. The inspectors that are registered with the WCF runtime receive the messages before they are passed on to the application or sent to the wire, depending on whether it is an incoming or outgoing message.

This way, it is possible to catch all HTTP responses coming from the web server, extract any cookies contained within the messages, and manually inject them in all subsequent HTTP requests on their way out. Here is a simplified view of the solution:

using System.ServiceModel;
using System.ServiceModel.Channels;

public class CookieManagerMessageInspector : IClientMessageInspector
{
    private string sharedCookie;

    public void AfterReceiveReply(ref Message reply, object correlationState)
    {
        HttpResponseMessageProperty httpResponse =
            reply.Properties[HttpResponseMessageProperty.Name]
            as HttpResponseMessageProperty;

        if (httpResponse != null)
        {
            string cookie = httpResponse.Headers[HttpResponseHeader.SetCookie];

            if (!string.IsNullOrEmpty(cookie))
            {
                this.sharedCookie = cookie;
            }
        }
    }

    public object BeforeSendRequest(ref Message request, IClientChannel channel)
    {
        HttpRequestMessageProperty httpRequest;

        // The HTTP request object is made available in the outgoing message only
        // when the Visual Studio Debugger is attacched to the running process
        if (!request.Properties.ContainsKey(HttpRequestMessageProperty.Name))
        {
            request.Properties.Add(HttpRequestMessageProperty.Name,
                new HttpRequestMessageProperty());
        }

        httpRequest = (HttpRequestMessageProperty)
            request.Properties[HttpRequestMessageProperty.Name];
        httpRequest.Headers.Add(HttpRequestHeader.Cookie, this.sharedCookie);

        return null;
    }
}

Message inspectors are enabled through the WCF extensibility mechanism called behaviors for single web service operations, entire web service contracts, or even specific endpoint URLs, depending on the scope the will operate in.

Here you can download a sample application showing how to implement a client-side message inspector to share the same cookies across multiple web services.

Download WCF Cookie Manager

/Enrico

The rise and fall of 3Dfx

The Christmas holidays usually mean taking a break from the usual everyday routine and focus more on the important relationships in our lives, like family and close friends. To me, this also somehow includes having the time to think about things technology-wise that either are new or haven’t crossed my mind in a long time.

During this past Christmas season, I strangely found myself thinking about a Christmas of the past, more precisely December of 1997. Why is this interesting? Because that was the year when I bought my first 3D Accelerator graphics card.

A little bit of history

Videogames have not always looked like they do today. Certainly they didn’t go straight from Pac-Man to Fallout 3 either.

There was a time in the early 90’s when game developers discovered that they could represent entire worlds using computer graphics and three-dimensional shapes. They also discovered that it was possible to cover those shapes with images instead of just applying some colors, to make them look more realistic. There was also a growing interest in reproducing physical aspects of the real world in 3D graphics, like the effects of lights and shadows, water, fog, reflexes etc.

Unluckily, the processing power of the CPUs available in the market at that time wasn’t quite up to the challenge. In spite of the advanced algorithms that were developed to render 3D graphics in software, the end results were always far from what we would call “realistic”.

The rise

Up until 1996, when a company called 3Dfx Interactive based in San Jose, California, published the first piece of computer hardware exclusively dedicated to rendering 3D graphics on a PC screen: a 3D Accelerator. Their product was called Voodoo Graphics, and consisted of a PCI card equipped with a 3D graphics processing unit (today known as GPU) running at 50 MHz and 4 MB of DRAM memory.

The company also provided a dedicated API called Glide, that developers could use to interact with the card and exploit its capabilities. Glide was originally created as a subset of the industry-standard 3D graphics library OpenGL, specifically focused on the functionality required for game development. Another key difference between Glide and other 3D graphics APIs was that the functions exposed in Glide were implemented directly with native processor instructions for the GPU on the Voodoo Graphics.
In other words, while OpenGL, and later on Microsoft’s Direct3D, provided an abstraction layer that exposed a common set of APIs independent of the specific graphics hardware that would actually process the instructions, Glide exposed only the functionality supported by the GPU.

This approach gave all 3Dfx cards superior performance in graphics processing, a key advantage that lasted many years, even when competing cards entered the market, such as the Matrox G200, ATI Rage Pro and Nvidia RIVA 128.
However, this also resulted in some heavy limitations in the image quality, like the maximum resolution of 640×480 (later increased to 800×600 with the second-generation cards called Voodoo 2) and the support for 16-bit color images.

The 3Dfx Voodoo Graphics was designed from the ground up with the sole purpose of running 3D graphics algorithms as fast as possible. Although this may sound as a noble purpose, it meant that in practice the card was missing a regular VGA controller onboard. This resulted in the need of having a separate video adapter just to render 2D graphics. The two cards had to be connected with a bridge cable (shown in the picture) going from the VGA card to the Voodoo, while another one connected the latter to the screen. The 3D Accelerator would usually pass-through the video signal from the VGA card on to the screen, and engaged only when an application using Glide was running on the PC.

Being the first on the consumer market with dedicated 3D graphics hardware, 3Dfx completely revolutionized the computer gaming space on the PC, setting a new standard for how 3D games could and should look like. All new games developed from the mid 90’s up to the year 2000 were optimized for running on Glide, allowing the lucky possessors of a 3Dfx (like me) to enjoy great and fluid 3D graphics.

To give you an idea of how 3Dfx impacted games, here is a screenshot of how a popular first-person shooter game like Quake II looked like when running in Glide-mode compared to traditional software-based rendering.

The fall

If the 3Dfx was so great, why isn’t it still around today, you might ask. I asked myself the same question.

After following up the original Voodoo Graphics card with some great successors like the Voodoo2 (1998), Voodoo Banshee, (1998) and Voodoo3 (1999), 3Dfx got overshadowed by two powerful competitors Nvidia’s GeForce and ATI’s Radeon. A series of bad strategic decisions that lead to delayed and overpriced products, caused 3Dx to lose market share, ultimately reaching bankruptcy in late 2000. Apparently 3Dfx, by refusing to incorporate 2D/3D graphics chips and supporting Microsoft’s DirectX, became no longer capable of producing cards that lived up to what was the new market’s standard.
In 2004 3Dfx opted to be bought by Nvidia, who acquired much of the company’s intellectual property, employees, resources and brands.

Even if 3Dfx no longer exist as a company, it effectively placed a landmark in the history of computer games and 3D graphics, opening the way to games we see today on the stores’ shelves. And the memory of its glorious days still warm the hearts of its fans, especially during cold Christmas evenings.

/Enrico