Повышение производительности с нулевыми, а не значения по умолчанию?

Question

Говорят, что преждевременная оптимизация - корень всего зла, но здесь все идет ...

У нас есть высокопроизводительное приложение;кэш в памяти, поддерживаемый Java на стороне сервера, и то, что должно быть очень быстрым C # GUI на стороне клиента.

Я отмечаю, что в настоящее время объекты, которые мы используем в кеше, имеют значения по умолчанию - например,инициализация строк по умолчанию "" и датами до 01.01.1999 вместо того, чтобы оставить их пустыми.

Теперь я могу быть очень привередливым, но разве это не добавляет чуть-чуть больше места на объект (как в кеше, так и при сериализации объекта), чем было бы иначе, если бы оно было нулевым?

Просто интересно, какого рода улучшения (если таковые имеются) будут достигнуты, когда наши объемы объектов начнут становиться достаточно высокими ...

Приветствия, Дейв.

Answer 1

Преждевременная оптимизация, безусловно, зло.

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

Несколько важных моментов:

• Есть некоторые (незначительные) преимущества в производительности при использовании null вместо значения по умолчанию.Для нативного кода легче проверить нулевое значение, чем для разыменования ссылки на объект и проверки значения этого объекта.Вы, вероятно, этого не заметите, если все находится в кеше L1, но если это приводит к отсутствию кеша в высокопроизводительном приложении, это может стать болезненным.
• Есть некоторые дополнительные затраты памяти, но, вероятно, это не имеет значениямного - при условии, что вы повторно используете одни и те же объекты значений по умолчанию много раз (т.е. многие ключи указывают на одно и то же значение), тогда не будет много дополнительных экземпляров объекта в целом.
• Если ваши значения по умолчанию равны неизменяемые одноэлементные объекты , тогда это очень помогает по трем причинам:
  • Вам нужна только одна копия неизменяемого объекта, а не разные экземпляры "" (String.intern () помогает здесь!)
  • Один и тот же объект, используемый много раз, с большей вероятностью будет эффективно кэшироваться
  • Вы можете использовать равенство ссылок (значение == DEFAULT_SINGLETON) для проверки значения по умолчанию, что позволяет избежать необходимости указателяразыменование, когда DEFAULT_SINGLETON является конечным статическим значением.
• Если вы используете неизменяемый синглтон defaПри работе со значениями ult будьте очень осторожны, чтобы не смешивать любые другие экземпляры с тем же значением. Это может произойти, например, при десериализации объектов - вам нужно использовать readResolve () и т. д., чтобы убедиться, что вы получите правильное значение синглтона на месте.

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

• Это немного быстрее и использует меньше памяти
• Скорее, это поможет вам обнаружить логическую ошибку (через громкое исключение NullPointerException, а не вызывать трудную для отслеживания ошибку сзначение по умолчанию используется вместо реального значения)