Conversion to DBObject is terribly slow [DATAMONGO-1116]

[spring-projects-issues]

Stepan Koltsov opened DATAMONGO-1116 and commented

Performance of java bean conversion to DBObject is terribly slow even for simple objects. For instance, in my test, conversion of very simple object of class:

class Foo { long id; String payload; ... } 

to DBObject takes about 8us.

I've written a self-contained perftest, have a look:

https://gist.github.com/stepancheg/0ef5ba9f347ffda1e88f

Results on my machine are:

auto: 8000ns
hand: 110ns

Conversion back is also too slow (but not terribly).

Peformance of conversion becomes a bottleneck in our application, and we even had to write conversions manually in several places.

We are using:

spring-data-mongodb-1.5.0
spring-data-commons-1.8.0
spring-core-4.0.7

---

Affects: 1.5 GA (Dijkstra)

Issue Links:

• DATAMONGO-712 Another round of potential performance improvements

[spring-projects-issues]

Oliver Drotbohm commented

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:

1. 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…
2. 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)