Jdbi: Penurunan kinerja yang signifikan sejak versi 3.5.1

Hai @Alexey1Gavrilov , terima kasih telah melaporkan ini! Saya setuju pasti ada beberapa regresi.

Saya mulai memperbaiki situasi: https://github.com/jdbi/jdbi/pull/1607
Saat ini, hanya menunggu review dan beberapa pengujian untuk memastikan kami tidak merusak semuanya :)

Apakah Anda punya waktu untuk memverifikasi secara independen bahwa perbaikan yang ditautkan di atas membantu kasus penggunaan Anda?
Terima kasih dan mudah-mudahan kami akan segera menggabungkan perbaikan.

Sebuah berita yang sangat baik bahwa Anda telah bekerja pada peningkatan! Saya dapat mengonfirmasi bahwa #1607 meningkatkan kinerja secara signifikan. Program benchmark mikro saya berjalan sekitar 10-15% lebih cepat dengan PR itu, kemudian pada 3.5.1. Kerja bagus!

Kami juga telah menerapkan lapisan cache khusus untuk pencocokan nama kolom yang meningkatkan kinerja lebih jauh. Idenya pada dasarnya adalah untuk men-cache perbandingan columnName dan javaName untuk semua bidang yang diproses oleh instance Jdbi . Berikut ini cuplikan kode:

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

Tolong beri tahu saya jika perbandingan nama kolom caching masuk akal bagi Anda (disertai dengan beberapa biaya pengumpulan sampah), jika saya dapat membuka PR.

@Alexey1Gavrilov , saya baru saja merilis 3.11.0 dengan #1607 disertakan.

Saya senang untuk meningkatkan kinerja pencocokan nama kolom, meskipun caching semua pencocokan mungkin merupakan solusi yang berat. Apakah Anda mengalami masalah dengan matcher tertentu -- mungkin matcher SnakeCase? Mari kita mulai dari deskripsi yang lebih baik tentang masalah yang memengaruhi Anda dan mencari solusi, yang mungkin berupa caching :)

Diuji 3.11.1 - peningkatan 20% dibandingkan dengan 3.5.1! Kerja bagus!
Saya akan membuat masalah terpisah pada pencocokan SnakeCase dan kami membahas kemungkinan solusi di sana.

Luarbiasa, terimakasih!