Hi Jeff, > * Objectify requires every class to be registered up front. This is > taking 5-8 seconds to regster 36 entity classes (plus a fair bit of > embedded structure). I am intimately familiar with what Ofy does > during registration - this isn't a computational cost. > > * I'm using Guice (development mode), but this isn't really the core > of the problem. The issue is that I'm using JAX-RS (Resteasy) to > support my REST API. In order for the @Path annotations to be > recognized, every resource class must be registered - and thus loaded. > There's ~80 of these classes. The Guice initialization part (which > includes Objectify registration) takes ~30s in production, ~15s in > sandbox. > > I don't see an obvious way to optimize this short of going back to > Java programming circa 2002. As long as my sitemap is defined by > @Path annotations and not a bunch of text in an xml file, those > classes are going to have to be loaded before my app starts. Entity > classes must be registered and introspected before any data is loaded > from the datastore.
I'm sorry if I miss something, but I don't think these kinds of introspection are fundamentally necessary because the class definition doesn't change during a single version, so you can introduce some caching mechanism. Also, I think there are some workaround like setting appropriate number of Min Idle Instances, or using backends instances. Didn't they help you here at all? > I'm not even asking for classpath scanning... I just want normal > classes to load in reasonable time. This problem is going to get > significantly worse over the next year. We add classes every day; our > app gets more features, not fewer. I guess my next experiment will > need to be JARing my WEB-INF/classes. 'Making class loading faster' would be definitely a constructive feature request. It's worth filing an issue and seeing how it interests people. Hi Thomas, On Mon, Jun 18, 2012 at 9:57 AM, Thomas Wiradikusuma <[email protected]> wrote: > Just my 2 cents, > > If indeed our app needs to be single-JARred and obfuscaticated (at least > removing unused code), IMO that feature should be baked in the tool. Probably > triggered with extra flag. I think this is also a good feedback especially if creating the single JAR contributes the performance. I'd appreciate it if you could file an issue. -- Takashi > > -- > 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/-/DX5yI2GRG9YJ. > 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?hl=en. > -- Takashi Matsuo | Developer Advocate | [email protected] -- You received this message because you are subscribed to the Google Groups "Google App Engine" 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?hl=en.
