I spent the weekend solving DATAMONGO-712 be removing the core hotspots I could identify using JMH and YourKit. I was able to increase the ops per second ration by 75%. I also see significant improvements when running your example. Generally speaking, I think your example is flawed for quite a couple of reasons:
micro-benchmarks usually do not reflect real application behavior. Of course, a generic, configurable mapping system will be much slower than just instantiating objects directly. In that regard your overly simplistic example plays into your hands: for a tiny object consisting of an identifier and a single property all of the features we actually provide are quite useless. Reading identifiers is quite a bit more expensive than reading normal properties. So if you add a few more properties to the type and populate them the big impact of the identifier mapping will decrease. Also, our mapping system has to deal with quite a few advanced use-cases: the usage of generics, inheritance, all stuff that users expect to just work out of the box need additional metadata, inspection of such etc. Still, I totally see that there is overhead, and that it's considerable. But even comparing absolute numbers is hardly valuable because of…
The amount of time spent in the mapping subsystem is usually not as high as the absolute numbers indicate compared to actual database interaction and other logic. Let's assume a pretty bad case: reading 100 documents into an object takes 200ns compared to 2ns for a direct conversion from the raw DBObject (thus, a factor of 100). Now assume you spend 30ms reading that data and another 40ms rendering a view on top of that. In total that makes 70.2ms VS. 70.002ms. So you factor of 100 all of a sudden collapsed to under 0,3%. Of course this is totally made up numbers. All I am trying to say is that without embedding the benchmark numbers into some context, it's really hard to claim, somethings "terribly slow".
I am closing this one as a duplicate of DATAMONGO-712. Happy to address further bottlenecks that can be pointed out by detailed profiler analysis (ops/s numbers before/after a patch)