Add EntityLite #13
Add EntityLite #13
Conversation
|
Thanks Jesus. I'll look at it shortly, I have time later this week to check out your additions so I can merge them :) |
|
It's not the fastest: Averaged total results per framework. Fastest and slowest result omitedNon-change tracking fetches, set fetches (10 runs), no cachingEntity Framework v6.0.0.0 (v6.0.21211.0) : 468,50ms. Enumeration average: 3,00ms Change tracking fetches, set fetches (10 runs), no cachingDataTable, using DbDataAdapter : 530,88ms. Enumeration average: 51,13ms Non-change tracking individual fetches (100 elements, 10 runs), no cachingEntityLite 1.0.10-Beta : 0,55ms per individual fetch Change tracking individual fetches (100 elements, 10 runs), no cachingOak.DynamicDb using typed dynamic class : 0,66ms per individual fetch Change tracking fetches, set fetches (10 runs), cachingLLBLGen Pro v4.1.0.0 (v4.1.13.1213) : 213,25ms. Enumeration average: 7,13ms Anyway, there are a couple of problems I have with your contribution. The first is that the benchmark is overly crowded with microORMs and I want to keep those at a minimum. The second is that your framework is barely used elsewhere. There's also a problem with the referenced assemblies (there's a version conflict, but vs.net doesn't say which one :( ), although I find that minor, compared to the other two problems. So it's not the code, which is fine, it's that I don't want the benchmark to become a test with tools which are not used by many. Therefore I'm going to decline your PR. I hope you don't take it the wrong way. It is quite fast, though it is in the same range as other micro ORMs, so the IL generated at runtime likely won't differ much between them. ;) |
|
Hi Frans, Thank you for spending your time on taking a look on my pull request. I hoped you accepted the pull request. EntityLite is new, still in beta, and threrefore nobody knows it yet. It would have been great that EntityLite was in your benchmark because more people would know it. Thank you anyway The first time I executed your benchmak, EntityLite was the fastest. Subsequent benchmaks, wasn't, sometimes was the fastest, sometimes was not. Your benchmark not always shows the same results. Please, can you tell me what is the problem with the referenced assemblies? I'm not aware of it. Could you help me to solve it? Thank you again. |
|
I just wanted to add a comment on these numbers: Entity Framework v6.0.0.0 (v6.0.21211.0) : 468,50ms. Enumeration average: 3,00ms How can Handcoded materializer using DbDataReader be slower than EntityFramework and EntityLite? And these: How can Handcoded materializer using DbDataReader be on the 5th position? It seems that something is wrong |
|
I also would like to thank you for including the benchmark results in your comments. Although I liked to see Handcoded materializer using DbDataReader the fastest as is actually is. I'm writing a CodeProject article introducing EntityLite that I'm going to send to CodeProject next weeks. May I reference these comments on the article? |
It might differ a lot if you have the db locally as the db cpu time is then not available for the ORM code. It also might be due to a garbage collect or other things. The differences are very minor between runs though. The reference problem is something I couldn't solve, it's the error you get when one project in the solution references assembly X v1.0.0.0 and another project references X v1.0.1.0 or something, so a different version for the same assembly X. VS.NET doesn't tell which one it is, sadly.
It's a tiny bit slower than entitylight (3ms), which might be due to the IL you generate is perhaps a bit more efficient, e.g. your loop might be more efficient than the loop generated by the C# compiler. EF generates other code which is more efficient. I don't know what trick they're using, haven't looked into their codebase yet for that. The handcoded code is close to what people would write when they would write raw ado.net code, there might be some inefficiency in one or two of the statements, but it's rather minor.
sure, no problem :) Good luck with the article. :) |
The IL code I generate is not more efficient than the code generated by the C#, and the handcoded materializer code is more efficient than EntityLite. In EntityLite I call IsDBNull for each field, handcoded materializer doesn't, the IL generated DynamicMethod is just for create an object and setting its properties from the datareader, the datareader looping code is outside the DynamicMethod. The DynamicMethod is cached, but there is an overhead to locate it in the cache, mostly because the cached method must conform with the datareader schema. |
|
|
I found the reason why it's faster: there were no FK fields present in the EF code. When adding them, their materializer isn't magically faster, but actually of normal performance and slower than the handwritten one. |
|
Sorry from come back here so late.
But only for nullable columns. I call it for every column.
But in the "Non-change tracking individual fetches" benchmark, which shows EntityLite faster than hand-coded materializer, It is for every row as well, since the query returns just one row. I believe there should be something that is causing different results on each benchmark run, such as other processes running on the machine.
I'm glad to hear that. |
|
I also would like to add a last comment
Based on your results It is. It's the fastest in Non-change tracking individual fetches, and the second in Non-change tracking fetches, set fetches. But Entity Framework which is the winner in Non-change tracking fetches, set feches, it is the 8th in Non-change tracking fetches. Therefore EntityLite is the fastest in non-change tracking fetches. EntityLite doesn't support change tracking. |
|
I published the CodeProject article where I referenced your blog post and mentioned your ORM: |
|
Article looks nice, lots of info! Looks like a good showcase for your framework :) |
|
Thanks Frans :-). I think It's very dense, it's not very easy to read. I'm not going to ask my girlfriend to read it. |
|
Haha :) nah, it has a lot of info, so that tends to get more dense than light articles which only describe one thing, but for people interested in the tool it covers most of the things to describe so why limit it :)
|
EntityLite is the fastest