Ok, I have figured out what's going on. To put it gently, the benchmark is bogus.
The benchmark code for the Low-Level API just gets the size() of the collection and doesn't actually examine the data. GAE (apparently) lazily populates Entity objects, so the benchmark cuts out a significant chunk of the work. Objectify eagerly examines the Entity data to create POJOs - but your real-world app is going to fetch the data from the Entity too. Presumably Slim3 lazily passes through to the low-level size() method. This is unrealistic; if you wanted a count, you would use the query's count() method. When you iterate the result set and include an Entity.getProperty() call, Objectify's 100ms overhead fades into the natural (+/- 500ms) variance. Sloppy work. Jeff On Wed, Jun 8, 2011 at 1:44 AM, Jeff Schnitzer <j...@infohazard.org> wrote: > Hmmmm. I just whipped up a test app that uses a mock > AsyncDatastoreService to provide a set of 10,000 Entity objects to > Objectify, thus purely measuring the overhead of Objectify. It > consistently transforms 10,000 entities into POJOs (just long id, > String value) in 100ms on both my laptop and on the production > servers. > > I'm not quite sure what's going on here, but it's not an issue with > reflection. > > Jeff > > On Tue, Jun 7, 2011 at 8:51 PM, Yasuo Higa <higaya...@gmail.com> wrote: >> I added an objectify sample into the performance samples: >> http://slim3demo.appspot.com/performance/ >> >> One result: >> The number of entities: 10000 >> low-level API:get: 1276 millis >> Slim3: 1327 millis >> Objectify: 3028 millis >> JDO: 3222 millis >> >> I have not profiled yet. >> But I know java runtime reflections are very very slow on production server, >> so slim3 creates the mapping logic between a model and an entity >> as the source code when compiling. >> >> Yasuo Higa >> >> On Wed, Jun 8, 2011 at 10:18 AM, Ikai Lan (Google) <ika...@google.com> wrote: >>> I doubt the low-level API is significantly faster than JDO (have not >>> profiled, so can't tell you for sure). JDO just dispatches to low-level and >>> does serialization/deserialization. That should really be a very small part >>> of the entire operation. >>> Reasons to use the low-level API include: >>> - it maps best to how the datastore works (schemaless) >>> - you always get new features the fastest (async datastore API) >>> That being said, the Slim3 and Objectify projects move pretty quickly and >>> add features almost as quickly as we do. They're one level removed from the >>> schemaless nature of the datastore, but this fits better with the 95% use >>> case. >>> >>> Ikai Lan >>> Developer Programs Engineer, Google App Engine >>> Blog: http://googleappengine.blogspot.com >>> Twitter: http://twitter.com/app_engine >>> Reddit: http://www.reddit.com/r/appengine >>> >>> >>> On Wed, Jun 8, 2011 at 8:07 AM, Dennis Peterson <dennisbpeter...@gmail.com> >>> wrote: >>>> >>>> That makes more sense, thanks. >>>> I also found this online benchmark of JDO and LL, which has similar >>>> results: >>>> http://gaejava.appspot.com/ >>>> >>>> On Tue, Jun 7, 2011 at 8:03 PM, Anders <blabl...@gmail.com> wrote: >>>>> >>>>> Yeah, that's what I suspected. Lazy loading. With the modification Slim3 >>>>> is almost as fast as the native API. Strange that JDO is so slow. I >>>>> thought >>>>> most of the time was for accessing the datastore, not for running the Java >>>>> bytecode. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google Groups >>>>> "Google App Engine" group. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msg/google-appengine/-/dHRvXzBkWVNkUndK. >>>>> To post to this group, send email to google-appengine@googlegroups.com. >>>>> To unsubscribe from this group, send email to >>>>> google-appengine+unsubscr...@googlegroups.com. >>>>> For more options, visit this group at >>>>> http://groups.google.com/group/google-appengine?hl=en. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "Google App Engine" group. >>>> To post to this group, send email to google-appengine@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> google-appengine+unsubscr...@googlegroups.com. >>>> For more options, visit this group at >>>> http://groups.google.com/group/google-appengine?hl=en. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Google App Engine" group. >>> To post to this group, send email to google-appengine@googlegroups.com. >>> To unsubscribe from this group, send email to >>> google-appengine+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/google-appengine?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google App Engine" group. >> To post to this group, send email to google-appengine@googlegroups.com. >> To unsubscribe from this group, send email to >> google-appengine+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/google-appengine?hl=en. >> >> > -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
