Is WCF faster than ASP.NET? Of course not! Or is it?

I was casually browsing Reddit when I came across a comment that triggered me. I’m paraphrasing¹, but the gist of it was that ‘WCF is faster than Web API or ASP.NET Core’. Surely, that was a mistake.

Boy, I’ll show them. What are they claiming, actually? ‘The response times of a WCF service are much lower than those of ASP.NET Web API or ASP.NET Core MVC.’ Pfft. I’ll just write a small benchmark using trusty ol’ BenchmarkDotNet. Stand up a local web server, measure how long it takes to create a request, send it, deserialize it, generate a response, send that back, and deserialize the response. One method will use WCF, the other will use ASP.NET Web API. To quote a colleague of mine: ‘how hard could it be?’

If you’re only interested in the complete picture, take a look at the full table of results and the graphs.

First steps

I’m sending 100 very simple objects (a single property that is a GUID) to the API and it’s sending 100 items back. Writing the benchmark wasn’t hard, but processing the outcome was, kind of. WCF was faster than ASP.NET Web API.

And not just a little bit faster; WCF is putting Web API to shame by taking less than a third of the time. Alright, but Web API is a pretty obsolete technology. Surely the new and shiny ASP.NET Core MVC will do much better. Right?

Well, it’s a little faster, but WCF still takes less than a third of the time.

Different formats

What’s so different between WCF and the other two options? Well, there is a pretty obvious difference: WCF is serializing data to and from XML (SOAP, to be precise), while for Web API and ASP.NET Core MVC, I was defaulting to JSON. What if I force the APIs to use XML?

There’s a definite improvement there. WCF is still a lot faster, but at least this shows we can get better results by picking a different serializer.

MessagePack

So what’s the fastest serializer we can find? According to their own claims, MessagePack is a small and fast format, and Yoshifumi Kawai has written a high-performance MessagePack serializer for .NET that beats protobuf-net, the default Protobuf serializer for .NET. Protobuf was designed to be easy to serialize and is known for its performance. Let’s see.

It’s going in the right direction. But can we go any faster? Probably not without extensive customization. However, these benchmarks have all been about serializing and deserializing 100 very simple objects. In the real world, objects are usually more complex than just a single GUID property.

Larger objects

Let’s try a more complex object.

public class LargeItem
{
    public Guid OrderId { get; set; }
    public ulong OrderNumber { get; set; }
    public string EmailAddress { get; set; }
    public Address ShippingAddress { get; set; } = new Address();
    public Address InvoiceAddress { get; set; } = new Address();
    public DateTimeOffset RequestedDeliveryDate { get; set; }
    public decimal ShippingCosts { get; set; }
    public DateTimeOffset LastModified { get; set; }
    public Guid CreateNonce { get; set; }
    public List<OrderLine> OrderLines { get; set; }
}

public class OrderLine
{
    public string Sku { get; set; }
    public int Quantity { get; set; }
    public string Product { get; set; }
    public decimal Price { get; set; }
}

public class Address
{
    public string Name { get; set; }
    public string Street { get; set; }
    public string HouseNumber { get; set; }
    public string PostalCode { get; set; }
    public string City { get; set; }
    public string Country { get; set; }
}

This is an order with order lines, copied from one of my other projects. There is a reasonable number of properties there, so let’s see how it goes.

Bingo. When serializing and deserializing 100 ‘large’ items, MessagePack on either ASP.NET Web API or ASP.NET Core MVC beats WCF by a small margin.

#itdepends

As usual, the answer to the question ‘which is faster’ is: it depends. When performance is absolutely critical, and your service doesn’t have to be a public API that anyone can consume, WCF is probably your best bet, up to a certain point. When you need to communicate large amounts of complex data, MessagePack on top of ASP.NET Core MVC is probably a better solution. Also worth considering is the developer-friendliness, where WCF doesn’t score very high marks.

What about JSON? The default library for working with JSON in .NET is Newtonsoft.Json. It’s great when you have to have absolute control over how your JSON looks, but it’s by far the slowest option I’ve examined. Can we have our cake and eat it too?

Utf8Json

It turns out that, yes, we can. Sort of. Yoshifumi Kawai, who you’ll remember as the author of the very fast MessagePack serializer for .NET, has also written a performance-oriented JSON serializer for .NET called Utf8Json. It’s not as customizable and it doesn’t support DOM operations, but man, is it fast.

It’s not as fast as WCF, and definitely not as fast as MessagePack, but it easily takes less than half the time that Newtonsoft.Json does. It does this by avoiding memory allocations (similar to the MessagePack serializer) and by treating JSON as a binary format; it doesn’t serialize to a string which is then converted into bytes, but instead it serializes straight to UTF-8 bytes².

Conclusion

As I said before, it depends. If round-trip time performance is more important than pretty much anything else, but you still want to use a managed language, use WCF. If you care about performance, but also about legible and easy to use code, or you want to create a proper REST-ful service, use MessagePack or Utf8Json on top of ASP.NET Core MVC or ASP.NET Web API.

The code I’ve used to benchmark these libraries is available on GitHub. Feel free to play around with it, and maybe find even better options.

Data

Below you’ll find the ‘raw’ output from the benchmark I’ve run. Some annotations:

• A method prefixed with ‘Small’ means it serializes and deserializes a small class with only a single GUID property. ‘Large’ means it serializes and deserializes the large class described above.
• All WCF methods are hosted using WebServiceHost;
• All WCF methods use a ChannelFactory client, while the Web API and ASP.NET Core MVC methods use System.Net.HttpClient³;
• WcfText uses a BasicHttpBinding with the message encoding set to Text;
• WcfWebXml and WcfWebJson use a WebHttpBinding, with, respectively, XML or JSON as the message format;
• JsonNet methods use Newtonsoft.Json to serialize objects;
• I’ve included ‘0 items’ as an indication of how fast the client and web server/framework are;
• The ‘P95’ column represents the 95th percentile value of the response time;
• The ‘Gen 0’, ‘Gen 1’ and ‘Gen 2’ columns represent the number of garbage collections per 1 000 invocations;
• The ‘Allocated’ column represents the total amount of memory allocated for each invocation;

Some interesting data points that jump out:

• At 0 items, ASP.NET Core makes significantly fewer allocations, and as a result, it is the only option that results in no Generation 1 (or higher) allocations;
• Even with 0 items, the options using Newtonsoft.Json are a lot slower than any of the other options. There must be a lot of initialization happening;
• For larger item sizes, Utf8Json is frequently allocating the most memory of any option, but it still manages to be pretty fast. That just goes to show - avoiding memory allocation isn’t the only thing you need for speed;
• ASP.NET Core’s XML serializer is a lot slower than Web API’s - this is particularly visible for large items;
• WCF does very well in terms of allocated memory. If memory is constrained, WCF might be a viable option;

A note on the chart: I’ve tried my best to make it look good on desktop and on mobile, but the viewing experience is still best on a large screen.