Jdbi: Degradación significativa del rendimiento desde la versión 3.5.1

Hola @ Alexey1Gavrilov , ¡gracias por informar de esto! Estoy de acuerdo en que definitivamente ha habido algunas regresiones.

Empecé a trabajar para mejorar la situación: https://github.com/jdbi/jdbi/pull/1607
Actualmente, solo está esperando una revisión y algunas pruebas para asegurarse de que no rompamos todo :)

¿Tiene algo de tiempo para verificar de forma independiente que las correcciones vinculadas anteriormente ayuden a su caso de uso?
Gracias y espero que pronto tengamos una solución.

¡Una muy buena noticia que ya ha estado trabajando en la mejora! Puedo confirmar que el # 1607 mejora significativamente el rendimiento. Mi programa de micro benchmark se ejecuta aproximadamente un 10-15% más rápido con ese PR, luego en 3.5.1. ¡Buen trabajo!

También hemos implementado una capa de caché personalizada para el comparador de nombres de columna que mejora aún más el rendimiento. La idea era básicamente almacenar en caché la comparación de columnName y javaName para todos los campos procesados ​​por la instancia Jdbi . Aquí hay un fragmento de código:

class CachingColumnNameMatcher implements ColumnNameMatcher {
  private static class Column {
    final String columnName;
    final String javaName;

    private Column(String columnName, String javaName) {
      this.columnName = columnName;
      this.javaName = javaName;
    }

    <strong i="10">@Override</strong>
    public boolean equals(Object o) {
      if (this == o) {
        return true;
      }
      if (o == null || getClass() != o.getClass()) {
        return false;
      }
      Column column = (Column) o;
      return Objects.equals(columnName, column.columnName) &&
          Objects.equals(javaName, column.javaName);
    }

    <strong i="11">@Override</strong>
    public int hashCode() {
      return Objects.hash(columnName, javaName);
    }
  }

  private final ColumnNameMatcher delegate;
  private final ConcurrentMap<Column, Boolean> cache;

  CachingColumnNameMatcher(final ColumnNameMatcher delegate) {
    this.delegate = delegate;
    this.cache = new ConcurrentHashMap<>();
  }

  <strong i="12">@Override</strong>
  public boolean columnNameMatches(final String columnName, final String javaName) {
    final Column key = new Column(columnName, javaName);

    return cache.computeIfAbsent(key, (c) -> delegate.columnNameMatches(columnName, javaName));
  }
}

...
    final ReflectionMappers reflectionMappers = jdbi.getConfig().get(ReflectionMappers.class);
    reflectionMappers.setColumnNameMatchers(
        reflectionMappers.getColumnNameMatchers().stream()
            .map(CachingColumnNameMatcher::new)
            .collect(Collectors.toList()));
...

Por favor, avíseme si la comparación del nombre de la columna de almacenamiento en caché tiene sentido para usted (viene con algunos costos de recolección de basura), si puedo abrir un PR.

@ Alexey1Gavrilov , acabo de lanzar 3.11.0 con # 1607 incluido.

Me complace mejorar el rendimiento de la coincidencia de nombres de columna, aunque almacenar en caché todas las coincidencias es posiblemente una solución de gran peso. ¿Tiene problemas con un comparador específico, quizás el comparador SnakeCase? Comencemos con una mejor descripción del problema que lo está afectando e ideemos una solución, que posiblemente sea el almacenamiento en caché :)

Probado 3.11.1 - 20% de mejora en comparación con 3.5.1! ¡Buen trabajo!
Crearé un problema separado en el emparejador SnakeCase y discutiremos las posibles soluciones allí.

¡Increíble gracias!