Jdbi: Dégradation significative des performances depuis la version 3.5.1

Salut @Alexey1Gavrilov , merci d'avoir signalé cela ! Je suis d'accord qu'il y a certainement eu des régressions.

J'ai commencé à travailler pour améliorer la situation : https://github.com/jdbi/jdbi/pull/1607
Actuellement, il n'attend plus qu'une révision et quelques tests pour s'assurer de ne pas tout casser :)

Avez-vous le temps de vérifier de manière indépendante que les correctifs liés ci-dessus aident votre cas d'utilisation ?
Merci et j'espère que nous aurons bientôt un correctif fusionné.

Une très bonne nouvelle que vous avez déjà travaillé sur l'amélioration ! Je peux confirmer que #1607 améliore considérablement les performances. Mon programme de micro-repère s'exécute environ 10 à 15 % plus rapidement avec ce PR, puis sur 3.5.1. Bon travail!

Nous avons également implémenté une couche de cache personnalisée pour le matcher de nom de colonne, ce qui améliore encore les performances. L'idée était essentiellement de mettre en cache la comparaison des columnName et javaName pour tous les champs traités par l'instance Jdbi . Voici un extrait de code :

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()));
...

Veuillez me faire savoir si la comparaison des noms de colonnes de mise en cache a du sens pour vous (elle s'accompagne d'un certain coût de récupération de place), si je peux ouvrir un PR.

@Alexey1Gavrilov , je viens de publier 3.11.0 avec #1607 inclus.

Je suis heureux d'améliorer les performances de la correspondance des noms de colonnes, bien que la mise en cache de toutes les correspondances soit peut-être une solution lourde. Avez-vous des problèmes avec un matcher spécifique - le matcher SnakeCase peut-être ? Commençons par une meilleure description du problème qui vous affecte et concevons une solution, qui pourrait éventuellement être la mise en cache :)

Testé 3.11.1 - 20% d'amélioration par rapport à 3.5.1 ! Bon travail!
Je vais créer un problème séparé sur le matcher SnakeCase et nous y discuterons des solutions possibles.

Super merci!