SisoDb vs Entity Framework 4.1 Code first – Inserts

Before making any performance comparisions I just want to state the following:

I like Entity Framework Code first and I don’t see SisoDb as a complete replacement. SisoDb should be seen as a complement. Both tools have their place. EF being an O/RM and SisoDb being a document-oriented provider.

With that said, lets continue.

SisoDb – Simple Structure Oriented Db

I will not get into any details of what SisoDb is. If you are interested in knowing more I recommend the following:
SisoDb – Overview

Overview of the internal workings of SisoDb

For this post, just keep in mind that SisoDb is a document-oriented (in a NoSQL way of seing things) storage provider sitting on top of SQL Server. It’s not an O/RM.

Entity framework 4.1 – Code first

It’s being called the magical unicorn but I think it’s fair to say that EF Code first is nothing more than Microsoft first decent O/RM giving you a model first experience in .Net, much like the one NHibernate has been giving for years.

They are not the same

With EF you get a lot of O/RM like features like first level caching with identity maps, change tracking etc. It gives you a normalized database so that your object graphs gets stored in several tables. These tables needs to be joined to construct both queries and to return the resulting data for reconstructing your entities. This is a normal case of traditional relational database models used in RDMS.

With SisoDb you get simplicity. You get object-graphs stored as documents getting rid of all those joins. There’s no way to provide mappings and by using JSON you can of course work with base-classes, interfaces etc. You can also include/reference other documents which is returned in the same resultset as the main query. You can see each document/structure as an isolated store with no relations.

For dealing with JSON, SisoDb relies on a very fast library from ServiceStack. More info about the performance of this lib can be found here.

Testing environment

Both the application and the database (SQL Server developer edition) is executed on the same laptop. With 6GB RAM and an I7 Processor and a SSD disk on Windows 7 Ultimate, 64bit. Application was executed from within VS2010 in release mode and without debugger.

Performance – Simple inserts

For these simple inserts we will have a model looking like this:

Model for Simple inserts

In the aggregate root Customer there’s one difference between SisoDb and EF. In SisoDb the property by conventions must be named “SisoId”. In EF, this can be mapped but to get the convention support I’ll use “Id”.

public class Customer
    //public int SisoId { get; set; }

    //public int Id { get; set; }

    public int CustomerNo { get; set; }

    public string Firstname { get; set; }

    public string Lastname { get; set; }

    public ShoppingIndexes ShoppingIndex { get; set; }

    public DateTime CustomerSince { get; set; }

    public Address BillingAddress { get; set; }

    public Address DeliveryAddress { get; set; }

    public Customer()
        ShoppingIndex = ShoppingIndexes.Level0;
        BillingAddress = new Address();
        DeliveryAddress = new Address();

public class Address
    public string Street { get; set; }

    public string Zip { get; set; }

    public string City { get; set; }

    public string Country { get; set; }

    public int AreaCode { get; set; }

public enum ShoppingIndexes
    Level0 = 0,
    Level1 = 10,
    Level2 = 20,
    Level3 = 30


  • 1.1) Insert 1000 customers – Take 1 – without any optimazations
  • 1.2) Insert 1000 customers – Take 2 – with some optimazations
  • 2.1) Insert 10000 customers – Take 1 – without any optimazations
  • 2.2) Insert 10000 customers – Take 2 – with some optimazations
  • 3.1) Insert 100000 customers – Take 1 – without any optimazations
  • 3.2) Insert 100000 customers – Take 2 – with some optimazations

In Scenario 1.1 and 1.2, I iterated it five times and took the best value.
In Scenario 2.1 and 2.2, I itarated it two times and took the best value.
In Scenario 3.1 and 3.2, I itarated it two times and took the best value.

Also note that EF will not handle the enumeration in the model above. There are ways to get around this problem, but that’s not what this post is about.

Performance optimizations

During Scenario 1.2, 2.2 and 3.2 I used some small performance optimizations. I was a little bit more gentle to EF, by turning off some features.

ctx.Configuration.AutoDetectChangesEnabled = false;
ctx.Configuration.ProxyCreationEnabled = false;
ctx.Configuration.ValidateOnSaveEnabled = false;

By the way, feel free to tell me more things to configure to make it perform better.

For SisoDb there’s really is not optimazation. The point of SisoDb is to be simple and performant pout of the box. Although there is one feature you can take advantage off. You can tell SisoDb what to index(make queryable). In this case I selected only CustomerNo. It’s not a nice comparision but if you do have this scenario where you don’t plan on searching on just about everything, you can turn it off (

Simple inserts – Summary

  #1000 – #1 #1000 – #2 #10000 – #1 #10000 – #2 #100000 – #1 #100000 – #2
EF 0.83s 0.42s 50.85s 5.12s N/A 56.91s
SisoDb 0.09s 0.06s 0.86s 0.55s 8.71s 5.73s

Memory consumption

When inserting 100000 items with EF and the optimizations on, I got around 1GB of memory consumption. With SisoDb I got around 100MB of memory usage.

Source code

The source code for this article is hosted at Github:


This time I treated inserts of simple object graphs. Next post will be about complex inserts as well as reading/querying.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s