performance

Aug 21, 2012 at 6:19 AM

Looking forward to do better 希望提高改进一下性能

v2.2 FluentData  

Executing scenario: 
FetchSingleEntity 
-----------------------------------
Massive doesn't support the action. not explicit type support
Dapper entity - 500 iterations executed in 76,5396 ms
SqlFu Get - 500 iterations executed in 77,6155 ms
PetaPoco entity - 500 iterations executed in 78,8191 ms
SqlFu FirstOrDefault - 500 iterations executed in 80,1971 ms
OrmLite - 500 iterations executed in 80,2547 ms
InsightDatabase - 500 iterations executed in 160,2398 ms
FluentData - 500 iterations executed in 206,3038 ms

Executing scenario: FetchSingleDynamicEntity
-----------------------------------
SqlFu dynamic - 500 iterations executed in 74,6951 ms
Dapper dynamic - 500 iterations executed in 80,3824 ms
PetaPoco dynamic - 500 iterations executed in 83,6375 ms
Massive - 500 iterations executed in 130,8806 ms
OrmLite - 500 iterations executed in 146,8522 ms
InsightDatabase - 500 iterations executed in 176,2635 ms
FluentData - 500 iterations executed in 280,377 ms

Executing scenario: QueryTop10
-----------------------------------
Massive doesn't support the action. not explicit type support
SqlFu - 500 iterations executed in 90,7809 ms
PetaPoco - 500 iterations executed in 106,1067 ms
Dapper  - 500 iterations executed in 115,7401 ms
OrmLite - 500 iterations executed in 128,891 ms
InsightDatabase - 500 iterations executed in 203,417 ms
FluentData - 500 iterations executed in 445,0844 ms


Executing scenario: QueryTop10Dynamic
-----------------------------------
Dapper  - 500 iterations executed in 99,1737 ms
OrmLite - 500 iterations executed in 108,785 ms
Massive - 500 iterations executed in 116,3599 ms
SqlFu - 500 iterations executed in 116,4271 ms
PetaPoco dynamic - 500 iterations executed in 125,1672 ms
InsightDatabase - 500 iterations executed in 192,129 ms
FluentData - 500 iterations executed in 198,8402 ms 

Executing scenario: PagedQuery_Skip0_Take10
-----------------------------------
Dapper  doesn't support the action. No implicit pagination support
FluentData doesn't support the action. No implicit pagination support
OrmLite doesn't support the action. No implicit pagination support
InsightDatabase doesn't support the action. No implicit pagination support
Massive - 500 iterations executed in 115,4747 ms
SqlFu - 500 iterations executed in 199,1776 ms
PetaPoco - 500 iterations executed in 292,4833 ms 

Executing scenario: ExecuteScalar
-----------------------------------
OrmLite - 500 iterations executed in 59,7584 ms
InsightDatabase - 500 iterations executed in 64,2303 ms
PetaPoco int - 500 iterations executed in 66,3844 ms
SqlFu scalar int - 500 iterations executed in 77,7015 ms
Dapper scalar int - 500 iterations executed in 83,0212 ms
Massive - 500 iterations executed in 130,4026 ms
FluentData - 500 iterations executed in 157,6623 ms

Executing scenario: MultiPocoMapping
-----------------------------------
Massive doesn't support the action. Specified method is not supported.
OrmLite doesn't support the action. Suports only its own specific source format
InsightDatabase doesn't support the action. No implicit multi mapping support
SqlFu - 500 iterations executed in 75,7716 ms
Dapper  - 500 iterations executed in 88,3029 ms
PetaPoco - 500 iterations executed in 99,3068 ms
FluentData - 500 iterations executed in 236,9429 ms

Executing scenario: Inserts
-----------------------------------
Massive doesn't support the action. Couldn't figure how to insert pocos with auto increment id
FluentData doesn't support the action. Specified method is not supported.
InsightDatabase doesn't support the action. Specified method is not supported.
SqlFu - 500 iterations executed in 112,067 ms
PetaPoco - 500 iterations executed in 126,0432 ms
OrmLite - 500 iterations executed in 128,8205 ms
Dapper - 500 iterations executed in 264,1543 ms 

Executing scenario: Updates
-----------------------------------
InsightDatabase doesn't support the action. Specified method is not supported.
SqlFu - 500 iterations executed in 75,1604 ms
PetaPoco - 500 iterations executed in 80,522 ms
Dapper  - 500 iterations executed in 102,6581 ms
OrmLite - 500 iterations executed in 195,2351 ms
massive - 500 iterations executed in 202,5537 ms
FluentData - 500 iterations executed in 249,3975 ms 

Aug 21, 2012 at 9:27 AM

I'm aware of the result and the related blog post. My comments are:

1) The result you pasted are comparing pears with apples. For the other ORMs but FluentData a shared connection is opened before all the tests are executed, and this connection is never closed. While for FluentData the connection is opened and closed during each run. For 99,9% of the applications the best is to open the connection just before the query is executed and close it just after (unless you are doing bulk execution like the tests you pasted are doing - which 99.9% of the applications does not), and this is what FluentData does for you. And the reason for this is that its more critical to have connections that are never closed than to save some milliseconds. Anyways FluentData now supports UseSharedConnection where you can basically decide when to open it and when to close it. If the tests used this feature then the performance would be better.

2) Since the launch I have been transparent about the road map of FluentData. The first phases have focused on implementing the most important features that I think a framework like FluentData should have but with less focus on performance. Currently there is 1 feature left in this phase. In the next phase I will focus strictly on performance optimization. You can see the road map here: https://trello.com/board/fluentdata/4e9e67b519c2820000029f57.

3) FluentData has a easier to use and a more flexible API than the other frameworks, and it also has a better auto mapping support. This makes it easier to work with but it creates a small overhead. 

4) I have received a lot of feedback on FluentData through e-mail, and I'm yet to receive one concerning poor performance. There is a saying "premature optimization is the root of all evil".  The result shows a big gap between some ORMS and Fluent Data (but less when you use the UseSharedConnection feature), but does some tiny milliseconds matter in an average application (the result is for 500 executed queries)? In 99.9% of the cases it does not. And for every application that I have worked with any performance issue has been strictly due to poor SQL and not due to the framework.

5) In order to improve the performance to get close to for instance Dapper then I need to implement IL Emit where you create and cache methods on the fly. This will make the source code of Fluent Data more complex and it will be unreadable and unmaintanable for 99.9% of the developers. I have not yet decided if I want to take that route. You can see some examples on IL Emit at the bottom of this page: http://msdn.microsoft.com/en-us/library/system.reflection.emit.ilgenerator(v=vs.95).aspx

 

Any comments?

Aug 21, 2012 at 9:56 AM

Thank you for your reply
very good ,I am very interested in that !

Aug 18, 2013 at 2:20 PM
I would keep it how you have it and not go the IL Emit route. People use Fluent because it's easy to use and I would stick to this goal. Milliseconds don't matter for most applications. Comparing FluentData performance to EF or NHibernate is what really matters.