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: [classlib][pack200][performance] Profiling unpacking scenario
Date Wed, 09 Jul 2008 17:20:18 GMT
I had disabled the compression in my test to throw away ZIP overhead
and focus on pack200 performance only. Thus the performance data is
not relevant to previous measurements. The data are assumed with
HARMONY-5900 incorporated.

Harmony's pack200: 43 secs (3.5 Mb/secs)
Sun's pack200: 9 secs (16.6 Mb/secs)

Profile:

22.0% java.util.HashMap.*
11.4% java.io.FileInputStream.readBytes()
 7.5% o.a.h.unpack200.bytecode.ClassConstantPool.addNested()
 6.9% java.util.zip.*
 5.6% o.a.h.pack200.BHSDCodec.decode()
 4.8% java.lang.*
 4.4% o.a.h.unpack200.IcBands.getRelevantIcTuples()
 3.9% o.a.h.unpack200.bytecode.forms.NoArgumentForm.setByteCodeOperands()
 3.2% o.a.h.unpack200.bytecode.ClassConstantPool.* (other)
 3.0% o.a.h.unpack200.bytecode.CodeAttribute.*
 2.8% java.io.FileOutputStream.writeBytes()
 2.8% o.a.h.unpack200.bytecode.ByteCode.*
 2.75% java.util.TreeMap.*

Note ArrayList is gone!
It seems like BHSDCodec.decode(), IcBands.getRelevanticTuples() and
NoArgumentForm.setByteCodeOperands() are next candidates for tuning.
After that, the performance improvement is not possible without deep
changes, like overall algorithmic improvements. Anyway, that should be
first, but I'm not familiar with the code yet. This can't stop us
though ;)

Thanks,
Aleksey.

On Wed, Jul 9, 2008 at 7:27 PM, Sian January <sianjanuary@googlemail.com> wrote:
> Thanks for doing that Aleksey.  In fact I think Sun's was 20 or 30 times
> faster before we started doing any performance optimizations, but it looks
> like there's still some ground that we could make up!
>
>
>
> On 08/07/2008, Aleksey Shipilev <aleksey.shipilev@gmail.com> wrote:
>>
>> Hi,
>>
>> I took the liberty of profiling of pack200 implementation on unpacking
>> scenario. Source data was obtained from Eclipse JDT jars, repacked in
>> single 60 Mb jar file, then packed with pack200 from Sun's JDK (-E9
>> used), resulting in 20 Mb pack200-compressed file. Then Sun JDK
>> 1.6.0_05 (Windows, -server) was used together with hprof (cpu=time) to
>> obtain the profile. My patch from HARMONY-5900 is onboard. The head of
>> the profile looks like this:
>>
>> 4.76% org.apache.harmony.unpack200.bytecode.ClassConstantPool.addNested
>> 4.22% java.util.HashMap.getEntry
>> 2.99% java.util.AbstractList$Itr.next
>> 2.92% java.util.AbstractList$Itr.hasNext
>> 2.84% java.util.ArrayList.get
>> 2.43% java.util.AbstractList$Itr.next
>> 2.41% java.util.HashMap.containsKey
>> 2.15% org.apache.harmony.unpack200.IcBands.getRelevantIcTuples
>> 2.00% java.util.HashSet.contains
>> 1.57% java.io.DataOutputStream.writeUTF
>>
>> Composite occupancy:
>>
>> 18.4% java.util.AbstractList
>> 18.0% java.util.HashMap
>> 15.8% java.util.ArrayList
>> 10.5% o.a.h.unpack200.bytecode.ClassConstantPool.*
>> 5.3%  o.a.h.unpack200.bytecode.CPUTF8.* (hashcode mostly)
>> 4.5% java.io.*
>> 4.5% java.lang.String.*
>> 4.4% o.a.h.unpack200.bytecode.ByteCode.*
>> 3.9%  o.a.h.unpack200.bytecode.Ic{Tuple|Bands}.*
>> 14.7% other
>>
>> So the main concern is Collections usage. ClassConstantPool uses Lists
>> excessively, so I suspect the significant amount of time is spent
>> there.
>>
>> NB:
>> Timings for the scenario (the less the better):
>> Harmony's pack200: 67 secs
>> Sun's pack200: 6 secs
>>
>> Yep, 10 times faster.
>>
>> Thanks,
>> Aleksey.
>>
>
>
>
> --
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>

Mime
View raw message