Análisis extremadamente lento de la zona horaria con el nuevo java.API de tiempo

Estaba migrando un módulo de las antiguas fechas de java al nuevo java.tiempo API, y notó una gran caída en el rendimiento. Se reducía al análisis de fechas con zona horaria (analizo millones de ellas a la vez).

El análisis de la cadena de fecha sin una zona horaria (yyyy/MM/dd HH:mm:ss) es rápido, aproximadamente 2 veces más rápido que con la antigua fecha de Java, aproximadamente 1,5 M de operaciones por segundo en mi PC.

Sin embargo, cuando el patrón contiene una zona horaria (yyyy/MM/dd HH:mm:ss z), el rendimiento disminuye aproximadamente 15 veces con la nueva API java.time, mientras que con la antigua API es casi tan rápido como sin una zona horaria. Consulte el punto de referencia de rendimiento a continuación.

¿Alguien tiene una idea si de alguna manera puedo analizar estas cadenas rápidamente usando la nueva API java.time? Por el momento, como solución alternativa, estoy usando la antigua API para analizar y luego convertir el Date a Instantáneo, lo cual no es particularmente agradable.

import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.time.format.DateTimeFormatter;
import java.time.format.DateTimeFormatterBuilder;
import java.util.concurrent.TimeUnit;

import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.BenchmarkMode;
import org.openjdk.jmh.annotations.Fork;
import org.openjdk.jmh.annotations.Measurement;
import org.openjdk.jmh.annotations.Mode;
import org.openjdk.jmh.annotations.OperationsPerInvocation;
import org.openjdk.jmh.annotations.OutputTimeUnit;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.State;
import org.openjdk.jmh.annotations.Warmup;
import org.openjdk.jmh.infra.Blackhole;
import org.openjdk.jmh.runner.Runner;
import org.openjdk.jmh.runner.RunnerException;
import org.openjdk.jmh.runner.options.Options;
import org.openjdk.jmh.runner.options.OptionsBuilder;

@OutputTimeUnit(TimeUnit.MILLISECONDS)
@BenchmarkMode(Mode.AverageTime)
@OperationsPerInvocation(1)
@Fork(1)
@Warmup(iterations = 3)
@Measurement(iterations = 5)
@State(Scope.Thread)
public class DateParsingBenchmark {

    private final int iterations = 100000;

    @Benchmark
    public void oldFormat_noZone(Blackhole bh, DateParsingBenchmark st) throws ParseException {

        SimpleDateFormat simpleDateFormat = 
                new SimpleDateFormat("yyyy/MM/dd HH:mm:ss");

        for(int i=0; i<iterations; i++) {
            bh.consume(simpleDateFormat.parse("2000/12/12 12:12:12"));
        }
    }

    @Benchmark
    public void oldFormat_withZone(Blackhole bh, DateParsingBenchmark st) throws ParseException {

        SimpleDateFormat simpleDateFormat = 
                new SimpleDateFormat("yyyy/MM/dd HH:mm:ss z");

        for(int i=0; i<iterations; i++) {
            bh.consume(simpleDateFormat.parse("2000/12/12 12:12:12 CET"));
        }
    }

    @Benchmark
    public void newFormat_noZone(Blackhole bh, DateParsingBenchmark st) {

        DateTimeFormatter dateTimeFormatter = new DateTimeFormatterBuilder()
                .appendPattern("yyyy/MM/dd HH:mm:ss").toFormatter();

        for(int i=0; i<iterations; i++) {
            bh.consume(dateTimeFormatter.parse("2000/12/12 12:12:12"));
        }
    }

    @Benchmark
    public void newFormat_withZone(Blackhole bh, DateParsingBenchmark st) {

        DateTimeFormatter dateTimeFormatter = new DateTimeFormatterBuilder()
                .appendPattern("yyyy/MM/dd HH:mm:ss z").toFormatter();

        for(int i=0; i<iterations; i++) {
            bh.consume(dateTimeFormatter.parse("2000/12/12 12:12:12 CET"));
        }
    }

    public static void main(String[] args) throws RunnerException {
        Options opt = new OptionsBuilder().include(DateParsingBenchmark.class.getSimpleName()).build();
        new Runner(opt).run();    
    }
}

Y los resultados de las operaciones de 100K:

Benchmark                                Mode  Cnt     Score     Error  Units
DateParsingBenchmark.newFormat_noZone    avgt    5    61.165 ±  11.173  ms/op
DateParsingBenchmark.newFormat_withZone  avgt    5  1662.370 ± 191.013  ms/op
DateParsingBenchmark.oldFormat_noZone    avgt    5    93.317 ±  29.307  ms/op
DateParsingBenchmark.oldFormat_withZone  avgt    5   107.247 ±  24.322  ms/op

ACTUALIZACIÓN:

Acabo de hacer algunos perfiles de java.clases de tiempo, y de hecho, el analizador de zona horaria parece ser implementado de manera bastante ineficiente. Solo analizar una zona horaria independiente es responsable de toda la lentitud.

@Benchmark
public void newFormat_zoneOnly(Blackhole bh, DateParsingBenchmark st) {

    DateTimeFormatter dateTimeFormatter = new DateTimeFormatterBuilder()
            .appendPattern("z").toFormatter();

    for(int i=0; i<iterations; i++) {
        bh.consume(dateTimeFormatter.parse("CET"));
    }
}

Hay una clase llamada ZoneTextPrinterParser en el paquete java.time, que está haciendo internamente una copia del conjunto de todas las zonas horarias disponibles en cada llamada parse() (a través de ZoneRulesProvider.getAvailableZoneIds()), y esto es responsable del 99% del tiempo pasado en el análisis de la zona.

Bueno, una respuesta entonces podría ser escribir mi propia parser de zona, que tampoco sería muy bueno, porque entonces no podría construir el DateTimeFormatter a través de appendPattern().