Ok, you actually got me to waste 1 hour on benchmarking and I hate to say that you are right. The use of reflexion seems not to be heavy enough to make the difference. Some extra features on slim3 make it slower when you don't make use them, I almost have a working path to avoid this problem, but even with the patch, both frameworks give almost the same performance
On Thu, Jun 9, 2011 at 10:15 AM, Dennis Peterson <dennisbpeter...@gmail.com>wrote: > Haha, excellent. I studied cargo cults a bit in anthropology classes, long > ago, and never suspected how relevant they would be. > > You would probably enjoy this: > > > http://www.fanfiction.net/s/5782108/1/Harry_Potter_and_the_Methods_of_Rationality > > > Until Google makes a change, maybe the other frameworks should try the same > trick? > > > > On Thu, Jun 9, 2011 at 8:31 AM, Jeff Schnitzer <j...@infohazard.org>wrote: > >> On Thu, Jun 9, 2011 at 1:32 AM, Gal Dolber <gal.dol...@gmail.com> wrote: >> > I am not comparing reflexion vs byte-code generation or anything like >> that, >> > apt generates code, is not a runtime technology. >> > Like or not reflexion is known to be slower than actually writing the >> code. >> >> This is entirely irrelevant. We've now established that the issue at >> hand is a strange quirk in the Low-Level API and has nothing to do >> with reflection. 100% (or close to it) of the performance "gain" of >> Slim3 is because it calls .size() on a List before iterating it. >> >> > Slim3 generates the minimal possible code you need to talk with the low >> > level api, if the low level bench is faster is just because its not >> > converting the Entity to the Pojo. >> >> You missed the point - in the benchmark, Slim3 was *faster* than the >> Low-Level API. This clearly indicated something was amiss, and now >> we've uncovered the actual cause. It turns out to be something quite >> interesting indeed. >> >> This is a classic case of what Feynman called Cargo Cult Science. You >> all believed that Slim3 should be faster than other APIs because code >> generation is faster than reflection, so when someone produced an >> ill-conceived benchmark that seemed to confirm your preconceived >> notion, you just accepted the entire narrative: "Slim3 is fast >> because it doesn't use reflection!" This is sloppy thinking (see: >> Confirmation Bias). >> >> If you haven't read this, it's a gem (I make a habit of re-reading it >> at least once a year): >> >> http://www.lhup.edu/~DSIMANEK/cargocul.htm >> >> Jeff >> >> -- >> 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 >> google-appengine-java@googlegroups.com. >> To unsubscribe from this group, send email to >> google-appengine-java+unsubscr...@googlegroups.com. >> 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 > google-appengine-java@googlegroups.com. > To unsubscribe from this group, send email to > google-appengine-java+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-appengine-java?hl=en. > -- Guit: Elegant, beautiful, modular and *production ready* gwt applications. http://code.google.com/p/guit/ -- 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 google-appengine-java@googlegroups.com. To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en.
