With a shower so the sentences might be a little better. Lazy Loading classes is a variation on the same Object creation stuff.
On warm up all you are doing is initializing Objects, and creating classes. If you lazy load those, whole branches of your code won’t do that until you need to use those things. As a result an “Empty” warm up can go from 15s to 2. your first request of type X will be 4s, and of type y will be 4s and Z will be 4s until you have paid 20% more than what the non-lazy version would be, but the advantage is that a “cold” request will be 2+4s not 15s This is especially useful when you have something like the “places” in this sample code that needs a whole bunch of objects that aren’t used anywhere else. And uses libraries no other part of the code shares. You aren’t making the code more efficient, and it sucks because you have to know what dependencies each bit of your code has or things explode (much like when you do threading) but when your goal is to reduce the maximum suckage for the end user and instead spread the suckage around. (like the walmart check out analogy) Lazy Object and Class creation can be a big win. Lastly, there are some really hierarchical objects in this code, which is great for Object oriented code writing and is easier on the dev, but I think that functionalizing some of this would speed up the code base pretty significantly as Objects with like 4 tiers in their hierarchy don’t store efficiently. If you do need those, create them with the hierarchy early rather than attaching to them later, because you get an intermediary copy of the old object in creating the new object. From: [email protected] [mailto:[email protected]] On Behalf Of André Pankraz Sent: Tuesday, July 24, 2012 5:25 AM To: [email protected] Subject: Re: [google-appengine] Re: Startup time exceeded...on F4?! You should really focus an general architecture of the app for optimizing...havn't looked into the provided example. Your micro-optimizing suggestions for Java ...I think all Java guys are like ROFL now. Star visa Full Imports, String Concatenations in this example visa StringBuilder Really, if I carefully craft line numbers or embed no debug info in classes I can generate byte-identical class files with either import and string style. Import statements are not stored at all in Java class code and this string+string in one expression automatically use the StringBuilder pattern. you can lazy load classes - I just fear you mean something different ;) and it's the same problem like separating end points into micro apps - complex business code doesn't work that way - you have to load all that stuff anyway. Am Dienstag, 24. Juli 2012 09:00:15 UTC+2 schrieb Brandon Wirtz: I like that you use +'s to concat strings, it shows a real lack of experience doing optimizations since that is the very first thing on every list. > System.out.println(new Date() + ":" + new Random().nextInt()); At least most of your code uses objects correctly I didn't find any instances of places you did a type conversion functionally. That is usually one of the lowest hanging fruits, because it creates additional objects, and is a memory hog. -- 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/-/iYnYrW5SL2EJ. 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. -- 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.
