Thanks for doing the profiling! I've submitted HARMONY-5902, which won't
cure everything, but at least gets a few of the obvious inefficiencies out.
I'm not sure we'll ever get to Sun's speed in Java (Sun has a C native
implementation) but we can at least get closer!
Andrew Jr.
On Tue, Jul 8, 2008 at 10:43 AM, Aleksey Shipilev <
[EMAIL PROTECTED]> 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.
>
