On Mon, Nov 17, 2008 at 5:15 PM, Tim Ellison <[EMAIL PROTECTED]> wrote: > Xiao-Feng Li wrote: >> On Mon, Nov 17, 2008 at 4:16 PM, Aleksey Shipilev >> <[EMAIL PROTECTED]> wrote: >>> Hi, Wenlong! >>> >>> On Mon, Nov 17, 2008 at 11:06 AM, Wenlong Li <[EMAIL PROTECTED]> wrote: >>>> I didn't try the repacking approach on SPECJVM2008.startup. In my >>>> mind, the repacking scheme may not be very helpful to performance as >>>> more time is spent in executing user's code (startup benchmark) rather >>>> than creating JVM. >>> So, again, if so... user experience wouldn't get better, maintainer >>> experience would get poorer -- what's the reason of repacking then? >> >> Are you still on the thread topic? ;) > > yes, I think he is right on topic! If repackaging into large JARs > reduces the maintainer's experience of Harmony and doesn't significantly > improve the start-up times then we will be doing ourselves a disservice. > >>> Copying Nathan, I wish we have the solid numbers before making any >>> claims. Can you give us a little? > > Show us the numbers ;-)
This is Wenlong's post on this thread: "All, Thx for all your nice comments and suggestion. Before trying your suggestion, here I would like to share some findings, and expect your thoughts. (a) As all jars reside in disk, the expensive I/O is a problem. For example, the first run takes 876 ms to create VM, while the following run takes only 170 ms. I think this is due to the disk cache warm-up problem. I did another experiment on Linux machine, where I put the all jars in the /dev/shm directory. We saw the first run has the same performance as the following runs, indicating pre-loading the data into memory or disk cache can speed up startup. (b) The bootclasspath.properties in lib/boot directory defines what jars will be parsed and loaded during startup. I just removed some jars, and found the startup time can be further reduced from 170 ms to 140 ms for the run with warm-uped disk cache. (c) As the compilation time is also high in client mode, I use the interperter mode to run the program, and found the time can decrease from 140 ms to 94 ms. Any thought? Thx, Wenlong" > I can;t help thinking that running less code during start-up will get us > further towards our goal, by profiling the start-up sequence and > optimizing it (including Aleksey's ideas on caching JAR parsing). > > Regards, > Tim > -- http://xiao-feng.blogspot.com
