Jdbi: تدهور كبير في الأداء منذ الإصدار 3.5.1

مرحبًا @ Alexey1Gavrilov ، شكرًا على الإبلاغ عن هذا! أوافق على وجود بعض الانحدارات بالتأكيد.

بدأت العمل على تحسين الوضع: https://github.com/jdbi/jdbi/pull/1607
حاليًا ، في انتظار المراجعة وبعض الاختبارات للتأكد من أننا لا نكسر كل شيء :)

هل لديك بعض الوقت للتحقق بشكل مستقل من أن الإصلاحات المرتبطة أعلاه تساعد في حالة الاستخدام الخاصة بك؟
شكرًا ونأمل أن يتم دمج الإصلاح قريبًا.

خبر سار جدًا أنك كنت تعمل بالفعل على التحسين! أستطيع أن أؤكد أن # 1607 يحسن الأداء بشكل كبير. يعمل برنامج القياس الجزئي الخاص بي أسرع بنسبة 10-15٪ تقريبًا مع ذلك PR ، ثم على 3.5.1. عمل عظيم!

لقد قمنا أيضًا بتنفيذ طبقة ذاكرة تخزين مؤقت مخصصة لمطابق اسم العمود الذي يعمل على تحسين الأداء بشكل أكبر. كانت الفكرة في الأساس تخزين مقارنة بين columnName و javaName لجميع الحقول التي تمت معالجتها بواسطة مثيل Jdbi . إليك مقتطف الشفرة:

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

واسمحوا لي أن أعرف ما إذا كانت مقارنة اسم عمود التخزين المؤقت منطقية بالنسبة لك (تأتي مع بعض تكلفة جمع القمامة) ، إذا كان بإمكاني فتح العلاقات العامة.

@ Alexey1Gavrilov ، لقد أصدرت للتو 3.11.0 مع تضمين 1607 #.

يسعدني تحسين أداء مطابقة اسم العمود ، على الرغم من أن التخزين المؤقت لجميع المطابقات قد يكون حلاً ثقيل الوزن. هل تواجه مشكلات مع مُطابِق محدد - ربما يكون مُطابق SnakeCase؟ لنبدأ من وصف أفضل للمشكلة التي تؤثر عليك ونبتكر حلاً قد يكون تخزينًا مؤقتًا :)

تم اختباره من 3.11.1 إلى 20٪ مقارنة بـ 3.5.1! عمل عظيم!
سأقوم بإنشاء مشكلة منفصلة على مُطابق SnakeCase ونناقش الحلول الممكنة هناك.

رائع شكرا لك!