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).


[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

View raw message