Micro ORM - Which to select?

Over the past week, I have been evaluating the three different micro orm choices in the ADO.NET arena. The three most popular seem to be Dapper, Massive, and PetaPoco. 

Scott Hanselman had an enlightening post on this topic about a year ago at: http://www.hanselman.com/blog/HanselminutesPodcast262TheRiseOfTheMicroORMWithSamSaffronAndRobConery.aspx. I believe that was just before PetaPoco started to gain notoriety as he covered only Dapper and Massive.

Massive is very flexible in that I am able to map the columns of the database to a dynamic object. However, I want to have strongly-typed objects in ScrumTime so this eliminates Massive.

Dapper appears to run the fastest from all that I have read and experienced on my own. It is very good at mapping database tables to strongly-typed objects for querying data. However, the process of inserting, updating, and deleting objects is not so clear. I have found that there is an extension to Dapper within the github Dapper repository that has insert, update, and delete capabilities. I am going to research that as soon as possible.

UPDATE (01/22/2013): Dapper has two separate extensions that offer two different excellent solutions to my concerns.  The two project names are Dapper.Contrib and Dapper.Rainbow.  The Dapper.Rainbow appears to be a perfect fit for what I was seeking.

PetaPoco is very promising. In fact, I have already made significant headway in using this ORM in my Product repository. I did have a small learning curve to overcome in using the SQL Builder that was included.

In general, I have debated the use of model attributes that identify the table name, primary key, etc. It seems to pollute the model with information that is not relevant to the model itself. It is more relevant to the method of storage which I intend to be encapsulated within the repository layer. But, I suppose it is much better than defining XML files as is the option in other more bloated ORMs. So, I am probably going to live with it because I cannot come up with an alternative that is as easy to follow as attributes. Therefore, I have no concrete concerns other than it seems to be a 'smell'.

At this time, I have reduced the three choices down to two choices: Dapper or PetaPoco. I suppose that is progress.

UPDATE (01/22/2013):  I found that Dapper and PetaPoco support of concept of "Multiple Querying" in order to solve one-to-many and many-to-one relationships.  I am a huge fan of this approach.  At this time, I am using PetaPoco only because it comes with a TT file for generating my model objects quickly.  I am sure I could create a TT for Dapper, but I have not had the time.