Должен ли я кэшировать System.getProperty ("line.separator")?

Question

Рассмотрим такой метод:

@Override 
public String toString() 
{ 
    final StringBuilder sb = new StringBuilder(); 
    for (final Room room : map) 
    { 
     sb.append(room.toString()); 
     sb.append(System.getProperty("line.separator")); // THIS IS IMPORTANT 
    } 
    return sb.toString(); 
} 

System.getProperty("line.separator") можно назвать много раз.

Следует ли кэшировать это значение с помощью public final static String lineSeperator = System.getProperty("line.separator") , а затем использовать только lineSeperator?

Или System.getProperty("line.separator") так же быстро, как использование статического поля?

Answer 1

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

@Override 
public String toString() 
{ 
    final StringBuilder sb = new StringBuilder(); 
    final String newline = System.getProperty("line.separator"); 
    for (final Room room : map) sb.append(room.toString()).append(newline); 
    return sb.toString(); 
} 

BTW Я проверил вызов.Код:

public class GetProperty 
{ 
    static char[] ary = new char[1]; 
    @GenerateMicroBenchmark public void everyTime() { 
    for (int i = 0; i < 100_000; i++) ary[0] = System.getProperty("line.separator").charAt(0); 
    } 
    @GenerateMicroBenchmark public void cache() { 
    final char c = System.getProperty("line.separator").charAt(0); 
    for (int i = 0; i < 100_000; i++) ary[0] = (char)(c | ary[0]); 
    } 
} 

Результаты:

Benchmark      Mode Thr Cnt Sec   Mean Mean error Units 
GetProperty.cache   thrpt 1  3 5  10.318  0.223 ops/msec 
GetProperty.everyTime  thrpt 1  3 5  0.055  0.000 ops/msec 

кэшируются подход более чем на два порядка быстрее.

Обратите внимание, что общее воздействие getProperty вызывает все строковое строение, очень маловероятно, чтобы быть заметным.

Answer 2

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

Кэширование значения, безусловно, быстрее, чем выполнение вызова снова и снова, но разница, вероятно, будет незначительной.

Answer 3

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

Если вы этого не сделали, то нет, поиск вряд ли будет иметь достаточное количество накладных расходов.

Это подпадает под любую или обе из общих категорий «микро-оптимизация» и «преждевременная оптимизация». :-)

---

Но если вы беспокоитесь об эффективности, вы, вероятно, много больше возможностей в том, что ваш метод toString перерождается строковый каждый раз. Если toString будет называться много, а не кешировать терминатор линии, кешируйте сгенерированную строку и очистите это, когда меняется ваша карта комнат. Например .:

@Override 
public String toString() 
{ 
    if (cachedString == null) 
    { 
     final StringBuilder sb = new StringBuilder(); 
     final String ls = System.getProperty("line.separator"); 
     for (final Room room : map) 
     { 
      sb.append(room.toString()); 
      sb.append(ls); 
     } 
     cachedString = sb.toString(); 
    } 
    return cachedString; 
} 

... и когда ваши изменения карты, сделать

cachedString = null; 

Это намного больше удара для доллара (доллар являются накладными расходами дополнительного поля). Предоставлено это для каждого экземпляра, а не для класса, поэтому (ссылайтесь на предыдущий комментарий об эффективности) делайте это только в том случае, если у вас есть все основания.

Answer 4

Поскольку так легко сделать, почему бы и нет? По крайней мере, реализация System.getProperty() должна будет искать хэш-таблицу (даже если она кэширована изнутри), чтобы найти запрашиваемое свойство, тогда виртуальный метод getString() будет вызываться в результирующем объекте. Ни один из них не очень дорогой, но его нужно будет называть несколько раз. Не говоря уже о том, что будут созданы временные файлы String и после этого им потребуется GCing.

Если вы переместите это в верхнюю часть цикла и повторно используете одно и то же значение, вы избежите всех этих проблем. Так почему бы не?

Answer 5

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

Например, текстовый генератор может использовать свойство для генерации текста для окон или для linux и разрешить динамическое изменение свойства в приложении, почему бы и нет?

В общем, улавливание имущества подразумевает использование бесполезной функции setProperty.