You are wrong. Try adding getProperty() calls to your LL performance test, and the speed advantage of the LL API goes away. I don't know what to say about Slim3, but here's my test case:
http://code.google.com/p/scratchmonkey/source/browse/#svn%2Fappengine%2Fperformance-test I created 10,000 entities in the datastore that have the same format as your test case - a single string property. Here's what happens (try it - and remember to reload the urls several times to get a realistic median value): ###### Low Level API with just .size() http://voodoodyne.appspot.com/fetchLLSize The code: List<Entity> things = DatastoreServiceFactory.getDatastoreService() .prepare(new Query(Thing.class.getAnnotation(javax.persistence.Entity.class).name())) .asList(FetchOptions.Builder.withDefaults()); things.size(); Note that results are almost always under 2000ms. Wild guess I'd say the median elapsed is ~1900, just like your example. ###### Low Level API with actual fetch of the data http://voodoodyne.appspot.com/fetchLL The code: List<Entity> things = DatastoreServiceFactory.getDatastoreService() .prepare(new Query(Thing.class.getAnnotation(javax.persistence.Entity.class).name())) .asList(FetchOptions.Builder.withDefaults()); for (Entity ent: things) { ent.getKey(); ent.getProperty("value"); } Note that the duration is now considerably longer. Eyeballing the median elapsed time, I'd say somewhere around 3000ms. ###### Objectify fetching from datastore http://voodoodyne.appspot.com/fetch Objectify ofy = ObjectifyService.begin(); List<Thing> things = ofy.query(Thing.class).list(); for (Thing thing: things) { thing.getId(); thing.getValue(); } Note that the timing is pretty much the same as the LL API when it includes actual fetches of the entity values. It is, no doubt, just a little higher. ###### A pure measurement of Objectify's overhead http://voodoodyne.appspot.com/fakeFetch This causes Objectify to translate 10,000 statically-created Entity objects to POJOs. You can see the code here: http://code.google.com/p/scratchmonkey/source/browse/appengine/performance-test/src/test/FakeFetchServlet.java You'll notice (after you hit the URL a couple times to warm up the JIT) that elapsed time converges to somewhere around 120ms. ----------- Conclusion: The numbers in the original benchmark are a result of improper measurements. The actual wall-clock overhead for Objectify in this test is ~4% (120ms out of 3000ms). Further speculation on my part, but probably correct: The overhead of reflection is unlikely to be a significant part of that 4%. Sloppy work. Jeff On Wed, Jun 8, 2011 at 7:55 AM, Yasuo Higa <[email protected]> wrote: > It is not bogus. > LazyList#size() fetches all data as follows: > public int size() { > resolveAllData(); > return results.size(); > } > > Yasuo Higa > > On Wed, Jun 8, 2011 at 11:32 PM, Dennis Peterson > <[email protected]> wrote: >> It's not my benchmark, it's Slim3's :) ...but you're right, it's bogus. I >> asked on the main appengine group too, and it turns out the low-level >> benchmark is doing lazy loading. With that fixed, their numbers come out >> like yours. >> I found this one too, which also gets results like yours: >> http://gaejava.appspot.com/ >> >> On Wed, Jun 8, 2011 at 4:44 AM, Erwin Streur <[email protected]> wrote: >>> >>> Indeed Dennis's measurements are very suspicious. First you should do >>> a couple of warming ups on each of the implementations to prevent >>> pollution like the JDO classpath scan for enhanced classes (which is >>> one of the reasons for the high initial run). Then do a couple of run >>> to determine a range of measurements to spot outlyers. your low-level >>> API 2millis is definately one. >>> >>> When I did the measurements I got the following results >>> low-level: 1150-1550 >>> Slim3: 1150-1600 >>> Objectify: 1950-2400 >>> JDO: 2100-2700 >>> >>> These measurements confirm that GAE designed implementations are >>> faster then the GAE implementation of a generic data access layer >>> (JDO), but not so extrem as initially posted. >>> >>> The initial response using JDO is a known issue and especially low >>> trafic website should not use it or use the always on feature (maybe >>> this will change in the new pricing model) >>> >>> Regards, >>> >>> Erwin >>> >>> On Jun 7, 11:00 am, Ian Marshall <[email protected]> wrote: >>> > The low-level API does indeed look very fast. >>> > >>> > Just a comment on JDO: repeat runs roughly halve the JDO run time. I >>> > presume that this is because for repeat runs the JDO persistence >>> > manager factory has already been constructed. >>> > >>> > On Jun 6, 8:44 pm, DennisP <[email protected]> wrote: >>> > >>> > > I'm looking at this online >>> > > demo:http://slim3demo.appspot.com/performance/ >>> > >>> > > Sample run: >>> > > The number of entities: 10000 >>> > > low-level API:get: 2 millis >>> > > Slim3: 2490 millis >>> > > JDO: 6030 millis >>> > >>> > > Is the low-level API really that much faster? >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Google App Engine for Java" group. >>> To post to this group, send email to >>> [email protected]. >>> To unsubscribe from this group, send email to >>> [email protected]. >>> For more options, visit this group at >>> http://groups.google.com/group/google-appengine-java?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Google App Engine for Java" group. >> To post to this group, send email to [email protected]. >> To unsubscribe from this group, send email to >> [email protected]. >> For more options, visit this group at >> http://groups.google.com/group/google-appengine-java?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "Google App Engine for Java" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-appengine-java?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
