Tim, I didn't spend more efforts to collect trace. Based on my experiment, reducing the number of loaded byte can help performance. Reducing the loading of zip can also help performance. But I don't collect exact performance data for each. Also adjusting the layout of zip in consecutive disk can also help performance. As I have reduced the VM creation time from 20+ seconds to 3 seconds on my windows machine, I suppose there would be small benefit when taking other approaches. But I believe they would help performance as you pointed out.
Thx, Wenlong On Sat, Dec 13, 2008 at 12:07 AM, Tim Ellison <[email protected]> wrote: > Wenlong Li wrote: >> The performance of on-demand library parsing is mostly from I/O (seek >> the jar, open the jar, read content for each class in the jar, etc). >> When disk cache is warm-up, the I/O impact is small, and then we see >> small performance improvement. > > Ok, so that says that better indexing of the bytes we need to load on > start-up won't necessarily help. We need to reduce the number of bytes > we load, or optimize the layout to help the loading speed up, right? > > Or do you mean the time is spent loading the ZIP directories (rather > than class file bytes)? > > Do you have some trace that shows what's happening? > >> You see the bootclasspath property is pre-defined in >> working_classlib\depends\files, so I pre-define another property file >> which saves the class library info for each package. I assume the >> library in each module will not change over time, just like the >> bootclasspath property file. Of course, when new module is added, we >> need update these properties. Question is how Harmony revises the >> bootclasspath property now? > > It is defined by parsing the bootclass.properties file. > >> I will think about how to automatically extract the package info from >> manifest of each module, and save them in my defined property file at >> compiling time. >> >> Suggestion and comments are welcome and appreciated. :) > > Don't bother yet :-) Seriously. > > If you say that the time is taken to seek and read the bytes for the ZIP > file directory... > ...then why stop at building the index to show where packages are? > ...why not build a full class level index? > > If you are saying that the time is spent loading the actual class files > from disk, and not parsing the ZIP directory entries to search for the > location of the bytes then this won't help and we need to layout the > bytes in a way that optimizes for start-up reading - or allow overlapped > reading and defer to the OS - or ? > > Regards, > Tim > >
