But back to the roots...long loops have nothing to do with class loading in java ;) imports and loops - we would be hard pressed to find a _relevant_ example. really... I don't believe you the Smart-Java-Guy story. 200 ms through import-reordering? nope...no imports in bytecode...just straigt bytecode with ful types: GET com.bla.C fieldname, INVOKE com.bla.D methodname methoddescriptor You know the GAE very well and for sure python and your cache stuff...but very often you generalize this for all and that gets really annoying.
You can "lazy load" classes if you don't use their functionallity, thats right - this classes are not fully loaded at the beginning. But many annotation-scanning frameworks (DI / O/R mapper etc.) in Java don't work this way. Am Dienstag, 24. Juli 2012 16:48:36 UTC+2 schrieb Brandon Wirtz: > > 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. > > > > > > > Am Dienstag, 24. Juli 2012 16:48:36 UTC+2 schrieb Brandon Wirtz: > > 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 view this discussion on the web visit https://groups.google.com/d/msg/google-appengine/-/mV8RrorNY2oJ. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
