harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Shipilev" <aleksey.shipi...@gmail.com>
Subject Re: [performance] Startup cost is high for Harmony (HARMONY-6002)
Date Mon, 17 Nov 2008 10:38:02 GMT
And once again, I would convince you to have industry-standard meaning
of what startup is for JRE, the knowledge already expressed in
SPECjvm2008:startup.* benchmarks. That is, the startup time is the
time required for first-time execution of application code, *not* the
VM boot time.

That's why I'm getting really frustrated when someone told me I should
place the burden of some infrastructural changes on maintainer -- for
some geeky pleasure like faster VM boot. I specifically say "geeky"
because this type of performance cost is not directly observed by the
end user, rather the user would observe significant improve in
compilation/interpretation times. To see how much "geeky" this stuff
is, we need to collect the performance profile for real startup
scenario [1].

That's why I'm asking how much the VM boot takes from overall startup
time on real startup scenario [1], so to conclude what's the benefit
of doing something on this stage. I'd rather be happier with wide view
on startup sequence before diving into optimizations (oops, that's
what Nathan said, again).

Thanks,
Aleksey.

[1] "Real" is more like Eclipse startup on top of Harmony or
SPECjvm2008:startup.*, rather Hello World.

On Mon, Nov 17, 2008 at 12:34 PM, Xiao-Feng Li <xiaofeng.li@gmail.com> wrote:
> 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