On Wed, Dec 10, 2008 at 10:07 PM, Tim Ellison <[EMAIL PROTECTED]> wrote: > Xiao-Feng Li wrote: >> On Wed, Dec 10, 2008 at 9:11 PM, Tim Ellison <[EMAIL PROTECTED]> wrote: >>> So my question is where is the time being saved using this technique? >>> >>> Is it the number of files we touch? e.g. disc seek time, or is it >>> searching through the ZIP directories looking for class files e.g. poor >>> ZIP performance for our usage, or ... >>> >>> Given that the cold start times improve by 85% (20s down to 3s), and >>> warm start improves by ~18% (170ms down to 140ms), it is most likely the >>> 'getting the bits off disc' part. Does that sound right? Can we >>> measure it? >> >> I am also wondering about it. There are two ways to save time: one is >> to reduce the number of JARs by repackaging all the classes; the other >> is to reduce the number of JARs loaded. As I know, the first approach >> helps little. That probably means the disk seeking time is the major >> contributor of startup time. >> >> If this hypothesis is correct, then to delay the loading of JARs can >> benefit even if all the JARs are needed in the end by an application. >> The reason is the IO time can be overlapped with the computation time. > > Yes, especially if we have the metadata that tells us where the classes > are stored. We can queue requests to load multiple class files > asynchronously in the file system. > >> Well, this solution might not really help, if an application (or >> benchmark) only measures the period after VM is launched. (This is >> probably true since a Java timer can be triggered only after VM is >> created, unless the benchmark measures the duration of twice VM >> instance creations.) > > Agreed, we should agree what we are optimizing, and why (the use case). > >>>>> I assume we could improve that by consolidating that metadata into a >>>>> file with faster access. >>>> Yes, below is what Wenlong's patch includes. >>>> >>>> +# The modulelibrarymapping properties show class libraries in each module. >>> I saw that, but not sure which problem it is solving >>> (seek times/parsing/other). Also, of course, this is a copy of the >>> metadata that we would need to keep in sync with changes to the module >>> manifests. I'd like the best of both worlds :-) >> >> Right. A "better" solution I can think of is, the runtime can extract >> this information at build time or installation time. It can be the >> next step if we think it is a valid solution. > > The OSGi frameworks must have this problem already. They need to > maintain a cache of bundles installed in the runtime without it being a > surprise each time they start up. While Wenlong's static cache is fine > for the prototype, there may be some code in Felix/whatever that we can > use to dynamically manage cached metadata for our modules.
Agreed. This kind of dynamic Felix-based way probably will be a long term ultimate solution. > p.s. Please don't take my comments as negative about the approach here. > I'm delighted to see this type of innovative work taking place. Definitely not negative. Comments are always welcome. And I think Harmony community needs more comments. :) > Regards, > Tim > > -- http://xiao-feng.blogspot.com
