How about an API for LLBLGen that does queries that match Micro ORMs for speed? So stripping out all functionality unnecessary to the most basic usage.

In fact why not take it a step further and make the query pipeline like node and the new ASP.net stuff in that you configure in only the features that are required?

Hi Ian,

To understand your post: In this context - What is Micro? - What is 'the most basic usage'? - What is the issue with the actual speed? And How a micro orm would solve it?

As a matter of fact, with the new SDK you could write your own target framework, set of templates, tasks, presets, etc. So indeed it's possible, but you have to write it

I don't think I can do a very good job of answering your questions. However take a look at this article.... http://www.mattjcowan.com/funcoding/2012/02/24/adding-llblgen-to-the-dapper-benchmark-test-project/

Clearly the Micro ORMs are doing things significantly quicker.

In the comments Frans says...

during fetching or other db interactions, some features have to be called, simply because they’re supported in the framework.

So my point is do queries without all the supported features when they're not being used.

Example: for 32K entities, we're not that slow: http://pastebin.com/3eqm7bn7. In the grand scheme of things, the rest of the calls to the fetch logic also take time and it might very well be the time difference you'll see (as you'll likely fetch way less data) isn't that big, if noticable at all).

We don't write a microORM as there are already so many, and you can add them to a project with our framework without a problem: if you have a particular fetch which is faster with dapper and you need it to be the fastest possible, use dapper for that query. thing is: most microORMs fetch readonly data, so there's e.g. no change tracking with microORMs, so writing back the data you fetched might be a challenge. So in these cases use our own framework.

Our current poco fetch pipeline for poco typedviews isn't 100% optimal, there is room for improvement, however not that much before we'll have to use IL generation. (and it's still faster than e.g. OrmLite ) Currently the code has to take care of situations where typeconverters might be in play and other things which might slow down the fetch a bit, but if the query e.g. doesn't have those, it doesn't skip these checks.

But overall, I doubt you'll notice the difference that much.