On 5 hours now of sleep so I can form sentences:
>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 Y'all'd be right if this was 100 lines of code in Java 101. What you aren't looking at is that what is slow in this code set is object creation and object recycling. You are right that Import Io.* And Import Io.Blah Import Io.Blah2 Results in the same code, What doesn't result in the same code is doing import Io.Blah in classa and import io.blah2 in classb and io.blah3 in classC because it changes the order and timing of the Object and imported Class Creation. + doesn't matter if you do it once, but at one point this code is doing up to 15k +'s in a loop, and + doesn't do efficient recycling of temporary/intermediary objects. So laugh all you want, but there are serious gains in profiling the code and seeing where object and memory manipulation are sub optimal, especially when you have long loops. The problem I see with you guys is that you don't test, "REAL" application you test micro bits of code and don't look at the impact or history of how the code got to where it is. You say "it doesn't matter in 4 lines of codes" but you don't have "THOSE" 4 lines of codes in your app, you have 4 lines intermingled in with 80 other lines that change what is going on. There are times when just changing the order of your Imports can add or remove 200ms to your app. As to architecture changes. No one liked those. Don't calculate hashes if you are already in a session, use memcache and instance cache. Thread really long loops. -- 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.
