Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversion to DBObject is terribly slow [DATAMONGO-1116] #2033

spring-projects-issues opened this issue Dec 10, 2014 · 1 comment

Conversion to DBObject is terribly slow [DATAMONGO-1116] #2033

spring-projects-issues opened this issue Dec 10, 2014 · 1 comment
in: mapping status: duplicate type: bug


Copy link

@spring-projects-issues spring-projects-issues commented Dec 10, 2014

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:

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:


Affects: 1.5 GA (Dijkstra)

Issue Links:

  • DATAMONGO-712 Another round of potential performance improvements
Copy link

@spring-projects-issues spring-projects-issues commented Jan 25, 2015

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)

@spring-projects-issues spring-projects-issues added type: bug status: duplicate in: mapping labels Dec 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
in: mapping status: duplicate type: bug
None yet

No branches or pull requests

2 participants