Jdbi: Deutliche Leistungseinbußen seit Version 3.5.1

Hallo @Alexey1Gavrilov , danke für die Meldung! Ich stimme zu, dass es definitiv einige Rückschritte gegeben hat.

Ich habe angefangen, an der Verbesserung der Situation zu arbeiten: https://github.com/jdbi/jdbi/pull/1607
Derzeit wartet es nur auf die Überprüfung und einige Tests, um sicherzustellen, dass wir nicht alles kaputt machen :)

Haben Sie etwas Zeit, um unabhängig zu überprüfen, ob die oben verlinkten Fixes Ihrem Anwendungsfall helfen?
Danke und hoffentlich haben wir bald einen Fix zusammengeführt.

Eine sehr gute Nachricht, dass Sie bereits an der Verbesserung gearbeitet haben! Ich kann bestätigen, dass #1607 die Leistung erheblich verbessert. Mein Micro-Benchmark-Programm läuft mit diesem PR ungefähr 10-15% schneller, dann auf 3.5.1. Gute Arbeit!

Wir haben auch einen benutzerdefinierten Cache-Layer für den Spaltennamen-Matcher implementiert, der die Leistung noch weiter verbessert. Die Idee war im Grunde, den Vergleich von columnName und javaName für alle von der Jdbi Instanz verarbeiteten Felder zwischenzuspeichern. Hier ist ein Code-Schnipsel:

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

Bitte lassen Sie mich wissen, ob der Vergleich der Caching-Spaltennamen für Sie sinnvoll ist (er ist mit einigen Müllsammelkosten verbunden), wenn ich eine PR eröffnen kann.

@ Alexey1Gavrilov , ich habe gerade 3.11.0 mit #1607 veröffentlicht.

Ich freue mich, die Leistung des Abgleichs von Spaltennamen zu verbessern, obwohl das Zwischenspeichern aller Abgleiche möglicherweise eine schwergewichtige Lösung ist. Haben Sie Probleme mit einem bestimmten Matcher – dem SnakeCase-Matcher vielleicht? Beginnen wir mit einer besseren Beschreibung des Problems, das Sie betrifft, und entwickeln eine Lösung, die möglicherweise Caching sein könnte :)

Getestet 3.11.1 - 20% Verbesserung im Vergleich zu 3.5.1! Gute Arbeit!
Ich werde ein separates Thema zum SnakeCase-Matcher erstellen und wir diskutieren dort mögliche Lösungen.

Genial, Danke!