harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wenlong Li" <wenl...@gmail.com>
Subject Re: [performance] Startup cost is high for Harmony (HARMONY-6002)
Date Thu, 06 Nov 2008 01:13:06 GMT

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

On Thu, Nov 6, 2008 at 12:45 AM, Mark Hindess
<mark.hindess@googlemail.com> wrote:
> In message <bdbaeccd0811031931o16ab41c5oeac5a8f2f0140d92@mail.gmail.com>, "Wenl
> ong Li" writes:
>> Another optimization in my mind is to reduce the disk I/O time, where
>> I could merge all jars into one big jar to provide .class file.
>> Another possible approach is to pre-load these jar files into disk
>> cache or memory (put all jars into /dev/shm directory under Linux OS).
>> What do you think? Any comments or suggestion are welcome and appreciated.
> As Regis says we probably don't want to break the modularity to solve this.
> Perhaps we can learn something from the "Booting Linux in five seconds"[0]
> work.  They use sReadahead to do all the I/O up front[1] maybe there is a way
> we do something similar for the "blocks" read on startup?
> Regards,
>  Mark.
> [0] http://lwn.net/Articles/299483/
> [1] Actually not upfront but using in an "idle" I/O scheduler but this isn't
>    really an option for us.

View raw message