Безопасно ли вообще предполагать, что toString () имеет низкую стоимость?

Question

Вы обычно предполагаете, что toString () для любого данного объекта имеет низкую стоимость (то есть для регистрации)? Я делаю. Это предположение верно? Если это имеет высокую стоимость, должно ли это быть обычно изменено? Каковы веские причины для создания метода toString () с высокой стоимостью? Единственный раз, когда меня беспокоит стоимость toString, - это когда я знаю, что это какая-то коллекция со многими участниками. От: http://jamesjava.blogspot.com/2007/08/tostring-cost.html

Обновление: еще один способ выразить это: вы обычно изучаете стоимость вызова toString для любого данного класса перед его вызовом?

Answer 1

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

В принципе, если вам требуется ToString () для больших объектов в повседневной работе вашей программы, то ваша программа просто сумасшедшая. Даже если вам нужно ToString () целое число для чего-то критичного по времени, ваша программа сумасшедшая, потому что она, очевидно, использует строку, в которой было бы целое число.

ToString () для сообщений журнала автоматически в порядке, потому что ведение журнала уже дорого. Если ваша программа работает слишком медленно, уменьшите уровень журнала! На самом деле не имеет значения, насколько медленно на самом деле генерируются сообщения отладки, если вы можете не генерировать их. (Примечание: ваша инфраструктура журналирования должна вызывать саму ToString (), и только тогда, когда предполагается, что сообщение журнала должно быть напечатано. Не выполняйте ToString () вручную, по пути в инфраструктуру журнала, Вы заплатите цену, даже если уровень журнала низкий, и вы все равно его не распечатаете! Подробнее об этом см. http://www.colijn.ca/~caffeine/?m=200708#16.)

Answer 2

Я всегда буду переопределять toString для добавления того, что, по моему мнению, мне понадобится для устранения проблем. Обычно разработчик может использовать его, вызвав сам метод toString или попросив другой класс вызвать его (println, logging и т. Д.).

Answer 3

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

Answer 4

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

Например, в Java StringBuilder будет предварительно выделять некоторое пространство, чтобы определенное количество добавления строки занимало линейное время. Он будет перераспределяться, когда у вас закончится свободное пространство.

В общем, если вы хотите добавлять последовательности вещей и по какой-либо причине не хотите делать что-то подобное, вы можете использовать списки различий . Они поддерживают линейное добавление времени, превращая последовательность в композицию функций.

Answer 5

Я бы не использовал toString () для объектов, отличных от базовых типов. toString () может не отображать ничего полезного. Он может перебирать все переменные-члены и распечатывать их. Может загрузить что-то еще не загруженное. В зависимости от того, что вы планируете делать с этой строкой, вам не следует создавать ее.

Обычно есть несколько причин, по которым вы используете toString (): регистрация / отладка, вероятно, наиболее распространена для случайных объектов; Отображение является общим для определенных объектов (например, чисел). Для регистрации я бы сделал что-то вроде

if(logger.isDebugEnabled()) {
    logger.debug("The zig didn't take off.  Response: {0}", response.getAsXML().toString());
}

Это делает две вещи: 1. Предотвращает построение строки и 2. Предотвращает ненужное добавление строки, если сообщение не будет зарегистрировано.

Answer 6

В общем, я не проверяю каждую реализацию. Однако, если я вижу зависимость от общих Apache, звонки тревоги срабатывают, и я смотрю на реализацию более внимательно, чтобы убедиться, что они не используют ToStringBuilder или другие зверства.

Answer 7

Моя мысль:

Да на объектах стандартной библиотеки

Нет на нестандартных объектах, если у вас нет исходного кода перед вами и вы можете проверить его.