MicroLite 5.0 – Performance Summary

We mentioned in the MicroLite 5.0 Released post that there has been some work internally in MicroLite to improve performance and reduce memory usage. We’ll dive into the details in future posts, but for now here’s a brief summary of some of the results.

The calls are based upon a single instance of an entity, with the action performed 100 times inside an individual transaction each time.

The INSERT, UPDATE and DELETE calls were performed against an instance (e.g.)


The SELECT call was performed against the identifier of an instance (e.g.)

var entity = session.Single<Entity>(id);

The test also included performing a SELECT query which resulted in 100 results using Fetch and Paged (e.g.):

var entities = session.Fetch<Entity>(
    new SqlQuery("SELECT * FROM Entity WHERE Id <= @p0", 100));

var paged = session.Paged<Entity>(
    new SqlQuery("SELECT * FROM Entity"),
    PagingOptions.ForPage(1, 100));

The tests were run on a virtual machine using a local SQLite database and the results are as follows:

Activity MicroLite 4.0 MicroLite 5.0 Improvement
INSERT 20.79 ms 15.70 ms 24.48% faster
UPDATE 21.26 ms 16.19 ms 23.85% faster
DELETE 14.13 ms 11.15 ms 21.09% faster
SELECT (Single) 13.36 ms   7.95 ms 40.49% faster
SELECT (Fetch)   4.07 ms   2.42 ms 40.54% faster
SELECT (Paged)   4.27 ms   2.28 ms 46.60% faster

The following are based upon the above tests run in a profiler.

Version CLR Heap Used CLR Heap Allocated Process Mem Used Process VM Size GC Count
MicroLite 4.0 565 KB 3.8 MB 72 MB 60 MB 28
MicroLite 5.0 395 KB 3.6 MB 69 MB 57 MB 17

8 thoughts on “MicroLite 5.0 – Performance Summary

  1. Pingback: Benchmarking MicroLite 4.0 part 1 | MicroLite ORM

  2. ericswann

    Hi Trevor, looks like nice work….is there any comparison to other MicroOrms out there or even to something like EF for similar operations? I came across your post while looking at which dapper alternatives were still active out there…and typically perf is a key aspect of choosing a Micro. Anyway…if you’ve done any comparative analysis, would be nice to see.

    1. trevorpilley Post author

      Hi Eric, I have a github repo which has some basic benchmarks in it https://github.com/TrevorPilley/MicroORM.Benchmark which you may find useful, it’s also a good way of seeing the differences between each API as I’ve coded them as similar as is possible to make sure the benchmark is as fair as it can be.

      Typically I find no clear winner when running it and often the number of instances used per operation gives different ORMs better or worse rankings. Also, bear in mind that the benchmarks are all against a local SQLite db and different databases and network latency will also affect your results.

      Personally, I’d recommend basing your choice on the features the ORM offers and which API you find the nicest to use – a few ms here and there isn’t going to make a noticeable difference in most applications but other features in MicroLite such as extensions, listeners and includes API may offer you more functionality whilst still being acceptably performant if not always the fastest for some activities.

      1. ericswann

        Cool, thanks for the benchmarks, I’ll check them out. Agree that between micros perf should be secondary to functionality (as long as it’s in the ballpark). I mainly want to verify that it is at least in the ballpark before trying something new. I didn’t really see anything in here regarding this: With so many other options out there (Dapper/Peta/Massive/Insight/etc…) what was missing for you that made you decide to write your own? Peta and Massive have been pretty dormant for a while, but Dapper still gets lots of love and Insight as well.

      2. trevorpilley Post author

        I did use PetaPoco for a while but I found that there were a few things that I disliked. Firstly and its a common theme with most other MicroORMs is that it’s designed to be newed up in code which tightly couples that code to a database, there was no interface which could be used for dependency injection and unit testing. Another annoyance was the lack of extensibility points (such as the listener concept in MicroLite). As for Massive, whilst an interesting use of dynamic, I didn’t like the developer experience as much with the lack of intellisense. Dapper is really fast for reads but didn’t have a nice story for writes and you had to write a lot more code to use it. Some of those may have been addressed since I started MicroLite.

  3. ericswann

    BTW…agree the insert/update story is well done. Would like a strongly typed criteria (or basic linq) to reduce string/typo issues for most simple queries…maybe if MicroLite works out for me I can look into that.


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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s