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.