Home > Aspects, Developing Using CodeFluent Entities, Producers > Fetch performance of CodeFluent Entities compared to others

Fetch performance of CodeFluent Entities compared to others

CodeFluent Entities has a great way to extend or modify generated code. This can be done through Custom Producers, Sub-Producers or Aspects. In fact, it can happen that you will meet very special requirements during your project, the kind of requirements that will involve some customizations to all of your code. Of course you don’t want to do this job manually by modifying each property or method in your project. Instead you can change the generated code to fit your expectations by using aspect. For a first introduction to aspect development in CodeFluent Entities please visit our blog.

In our situation, after reading Frans Bouma’s blog on benchmark of several ORMs of the .Net platform (Entity Framework, NHibernate, LLBLGen Pro, Linq To Sql and more), we wanted to integrate CodeFluent Entities to the benchmarks he made.

Integrating CodeFluent Entities to the benchmark project

First we downloaded the project from its GitHub repository.

After opening the RawBencher solution we created a CodeFluent Entities Model project:

CodeFluent Entities Project

Also we created a class library project to hold the code generated by CodeFluent Entities:

Class Library Project

Then we added one Business Object Model Producer and one SQL Server Producer to this project:

Solution Explorer

Here is the configuration for each producer:

Business Object Model

Business Object Model

Microsoft SQL Server

Microsoft SQL Server

Then we imported the AdventureWorks database to our CodeFluent Entities model:


Then select the Microsoft SQL Server importer:

SQL Server Importer

Finally, set the connection string as pictured below:

SQL Server importer configuration

Once the import from database was done we built the model project to generate C# code and database stored procedures. After this, for the final step we added a bencher class to call CodeFluent Entities generated code. We basically reproduced the same schema as the existing ones for other ORMs already set up in this benchmarking project.

We are now ready to start the benchmarking!

Running the benchmark and analyzing results

We ran the project in release mode and we got the following results:

Non-change tracking fetches, set fetches (10 runs), no caching:

  1. Handcoded materializer using DbDataReader: 214,63ms
  2. PetaPoco Fast v4.0.3: 285,50ms
  3. Dapper: 306,25ms
  4. Linq to SQL v4: 318,50ms
  5. PetaPoco v4.0.3: 355,00ms
  6. Entity Framework v6: 362,13ms
  7. CodeFluent Entities 551,00ms
  8. ServiceStack OrmList v4.0.9.0: 555,75ms
  9. LLBLGen Pro v4.1.0.0, typed view: 585,00ms
  10. Oak.DynamicDb using dynamic Dto class: 902,50ms

Non-change tracking individual fetches (100 elements, 10 runs), no caching:

  1. CodeFluent Entities: 0,18ms
  2. DataTable, using DbDataAdapter: 0,37ms
  3. Oak.DynamicDb using dynamic Dto class: 0,40ms
  4. LLBLGen Pro v4.1.0.0: 0,44ms
  5. Telerik DataAccess/OpenAccess Fluent v4.0.3: 0,50ms
  6. Telerik DataAccess/OpenAccess Domain v4.0.3: 0,50ms
  7. NHibernate v3.3.1.4000: 0,68ms
  8. Entity Framework v6: 1,85ms
  9. Linq to Sql v4: 2,89ms

We focused only on non-change Tracking mode because it is the one that matches CodeFluent Entities features.

We can see that CodeFluent Entities is ranked at the first place for single fetch operations. Also we can see that it is ranked 7th for the multiple fetch operations.

Of course each ORM offers different features and because of that some of them can have a more naïve approach than others which will check data type conversion for instance or check cache during the fetch. This will lead to a speed difference in execution time.

For example if you compare a SQL hand coded query against any ORM among the ones available in .NET, hand coded query will be for sure faster. In our case we can explain why CodeFluent Entities generated code is taking more time in the multiple set fetch operation. Basically the code generated is doing some additional operations that we can get rid of in this particular scenario:

For instance in this LoadAll method we do not need to check if an element is already contained in the inner list so we should remove the check:


Another example is the ReadReacord method, in this case we do not need to test if the reader is null or not, neither the options and since the type are secure and primitive types we do not need to use the CodeFluent Persistence GetReader methods a simple reader.GetIn32 or reader.GetDate can be used depending on the type:


After making these changes we can run the benchmark again to see what changed!

Running the benchmark with the adapted code

Here are the new result after code adaptation:

Non-change tracking fetches, set fetches (10 runs), no caching:

  1. Handcoded materializer using DbDataReader: 214,63ms
  2. CodeFluent Entities 273,25ms
  3. PetaPoco Fast v4.0.3: 285,50ms
  4. Dapper: 306,25ms
  5. Linq to SQL v4: 318,50ms
  6. PetaPoco v4.0.3: 355,00ms
  7. Entity Framework v6: 362,13ms
  8. ServiceStack OrmList v4.0.9.0: 555,75ms
  9. LLBLGen Pro v4.1.0.0, typed view: 585,00ms
  10. Oak.DynamicDb using dynamic Dto class: 902,50ms

After these changes CodeFluent Entities is now ranked at the 2nd place just after the hand coded query!

I will now show you how to make these custom changes more generic to apply them to the entire project for instance.

Understanding CodeFluent Entities Aspects

In CodeFluent Entities, the code generation process is model-first and continuous: from your declarative model, a meta-model will be inferred which code generators will then translate into code.

AspectAspects introduce a new notion allowing you to plug into this process. Using aspects you’ll be able to work on this in-memory representation of the model, before anything is produced and dynamically add/remove/modify elements in your model: this is what we call dynamic modeling. In a nutshell, in CodeFluent Entities, dynamic modeling is materialized as aspects and it allows developers to inject extra-behaviors in models.

You can easily see what the inferred model contains by selecting the option “View Inferred Model” on your project:

View Inferred Model

Then you can get details about any method or property of your code, for instance in our case the LoadAll method of the SalesOrderHeader entity:

Inferred Model

This inferred model will be used by the Business Object Model Producer we configured before to generate our code.

When you build your project, the enabled producers are instantiated to work on your model. With CodeFluent Entities you can interact at moment of the code production. For example you can change on the fly the behavior of your CodeDom producer (aka Business Object Model Producer) by accessing its instance:

CodeDomProducer codeDomProducer = Project.Producers.GetProducerInstance<CodeDomProducer>();

codeDomProducer.CodeDomProduction += (sender, e) =>
    //write your code here ...

And then you can manipulate this codeDomProducer object to change the body of your methods or do any other change to the generated code. In our case this will be very helpful to change the body of the LoadAll and ReadRecord methods.

Making code adaptation using aspects

In fact the changes we made can be reproduced automatically among the code by using a custom aspect that will interact with the Business Object Model Producer on the fly.

You can download the FastReader.xml file that contains the aspect we developed to make our customizations generic.

To remind you here is what the LoadAll method looked like before using the aspect:

LoadAll Before

Here is the new version of the same function:

LoadAll After

Another example is the ReadRecord method; here is what it was like before using the aspect:

Read Record Before

After enabling the aspect the method is replaced by a new one with the name FastReadRecord:

Read Record After

CodeFluent Entities offers many ways to customize the code generation and aspects is only one way among the others. In fact code customization can also be done by using sub-producers or patch-producers. Each technic has its pros and cons and in our case aspects was the best way to reach our goal. If you want to read more about sub-producers or patch producers please visit our blog here and here.

I hope this article helped you to figure out the flexibility of CodeFluent Entities.

Feel free to download and use the FastReader.xml aspect if you need.
Moreover, the full source code is available on our GitHub Profile.

Happy Adapting!

The R&D team.

  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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