harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [performance] Startup cost is high for Harmony (HARMONY-6002)
Date Mon, 17 Nov 2008 09:34:53 GMT
On Mon, Nov 17, 2008 at 5:15 PM, Tim Ellison <t.p.ellison@gmail.com> wrote:
> Xiao-Feng Li wrote:
>> On Mon, Nov 17, 2008 at 4:16 PM, Aleksey Shipilev
>> <aleksey.shipilev@gmail.com> wrote:
>>> Hi, Wenlong!
>>>
>>> On Mon, Nov 17, 2008 at 11:06 AM, Wenlong Li <wenlong@gmail.com> 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

Mime
View raw message