Hi Peter, On 9 Mar 2016, at 08:42, Peter Levart <peter.lev...@gmail.com> wrote:
> Hi Chris, > > While Attribute.Name.equals() should be comparably fast, what about > Attribute.Name.hashCode() ? Could you for example extend the > AvailableCharsetsCompare benchmark with a a @Setup method that constructs > (via Attributes.putValue(String, String)) a java.util.jar.Attributes instance > with available charsets as keys, then a @Benchmark method that traverses the > Attributes instance looking-up each available charset via the > Attributes.getValue(String) ... Just to see the relative amount of regression > that might be caused by constructing intermediate lowercase String(s)… Just for clarification, the change in java.util.jar.Attributes has nothing to do with the charsets. Attributes stores the individual attributes from the Jar Manifest. There are only a relatively small number of standard Attributes [1]. 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. It seemed to be a knock on effect of the use of the comparator ( which was trying to avoid the continuous allocation cost to toLowerCase during comparisons ). I don’t think this code is particularly performance sensitive, and especially not hashCode. Maybe a benchmark with a number of standard Jar file attributes would make sense? -Chris. [1] http://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html#Main_Attributes
