Производительность против немного более чистого кода: проверка атрибута перед vs во время цикла

#java

#java

Вопрос:

Я добавляю некоторые изменения в существующий код и заметил, что его можно было бы оптимизировать, предварительно проверив условие, однако это делает код максимально чистым.

Исходный код был примерно таким:

 private void changeProperties(String a, String b, Document doc) {
    if(!isEmptyOrNull(a)) {
        doc.setA(a);
    }
    if(!isEmptyOrNull(b)){
        doc.setB(b);
    }
    saveDocument(doc);
}
  

А затем я добавил метод, который просто взял бы список и вызвал приведенный выше метод, например

 private void updatePropertiesForDocuments(List<Document> docs, String a, String b) {
    docs.forEach(doc -> changeProperties(a, b, doc));
}
  

Затем я понял, что в новой функциональности атрибуты ‘a’ и ‘b’ всегда будут одинаковыми для каждого документа. С этой информацией я подумал, что довольно бессмысленно проверять, являются ли ‘a’ и ‘b’ нулевыми или пустыми для каждого отдельного документа (особенно, если список может быть довольно большим, например, 100 000 ).

Итак, я подумал, что было бы лучше просто выполнить нулевые проверки перед входом в цикл следующим образом:

 private void updatePropertiesForDocuments(List<Document> docs, String a, String b) {
    boolean isAMissing = isEmptyOrNull(a);
    boolean isBMissing = isEmptyOrNull(b);

    if(!isAMissing amp;amp; !isBMissing) {
        docs.forEach(doc -> {
            doc.setA(a);
            doc.setB(b);
            saveDocument(doc);
        });
    } else if(!isBMissing) {
        docs.forEach(doc -> {
            doc.setB(b);
            saveDocument(doc);
        });
    } else if(!isAMissing) {
        docs.forEach(doc -> {
            doc.setA(a);
            saveDocument(doc);
        });
    }
}
  

Я хотел бы знать, если размер документов большой (100 000 ), будет ли заметная разница в производительности или есть какая-то оптимизация «под капотом», которую выполняет JVM, что сделало бы бессмысленным вносить это изменение?

Комментарии:

1. У вас есть код, почему бы вам не профилировать его?

2. производительность здесь менее важна, чем более чистый код. Эта штука выглядит баааадно

3. Первый вариант выглядит для меня более чистым

4. Я говорю придерживаться более простого кода. Во-первых, changeProperties будет использоваться другими способами? Если это так, либо сейчас, либо в будущем, то вам нужна эта дополнительная логика. Кроме того, чтобы, возможно, позволить вам избежать профилирования… на ваш вопрос можно ответить, спросив «что saveDocument(doc); делает?». Если этот метод вообще что-то делает, две проверки перед его вызовом будут неуместны в сравнении.