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
