Hi Claes,

Here's the pre-post-patch comparison:

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.infra.Blackhole;

import java.util.concurrent.TimeUnit;
import java.util.jar.Attributes;

@BenchmarkMode(Mode.AverageTime)
@Warmup(iterations = 5)
@Measurement(iterations = 10)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Fork(1)
@State(Scope.Thread)
public class JarAttributesBench {

    /*

pre-patch:

Benchmark                            Mode  Cnt    Score    Error Units
JarAttributesBench.buildAttributes   avgt   10  814.876 ± 10.300 ns/op
JarAttributesBench.lookupAttributes  avgt   10  728.400 ±  4.005 ns/op

post-patch:

Benchmark                            Mode  Cnt    Score   Error Units
JarAttributesBench.buildAttributes   avgt   10  949.266 ± 8.422 ns/op
JarAttributesBench.lookupAttributes  avgt   10  890.683 ± 6.651 ns/op

    */

    private static final String[] keys = {
        "Manifest-Version", "Created-By", "Signature-Version",
        "Class-Path", "Main-Class"
    };

    private Attributes attributes;

    @Setup(Level.Trial)
    public void setup() {
        attributes = buildAttributes();
    }

    @Benchmark
    public Attributes buildAttributes() {
        Attributes attr = new Attributes();
        for (String key : keys) {
            attr.putValue(key, key);
        }
        return attr;
    }

    @Benchmark
    public void lookupAttributes(Blackhole bh) {
        Attributes attr = attributes;
        for (String key : keys) {
            bh.consume(attr.getValue(key));
        }
    }
}



... so nothing drastic.

On 03/09/2016 02:03 PM, Claes Redestad wrote:


On 2016-03-09 13:17, Peter Levart wrote:

When digging through old history to try to find out why java.util.jar.Attributes
was ever using ASCIICaseInsensitiveComparator, it was not clear that
performance was the motivation.

I guess looking-up a manifest attribute is not a performance critical operation, you are right.

Could this be an old startup optimization, since first call to String.toLowerCase/toUpperCase will initialize and pull in java.util.Locale and friends? If so it's probably not effective any more.

Could be, yes.


Coincidentally - due to a recent regression - we're currently spending quite a bit of time parsing manifests of all jar files on the classpath, making ASCIICaseInsensitiveComparator show up prominently in some startup profiles.

/Claes


Regards, Peter

Reply via email to