Ответ 1
литье в String дешевле, поскольку для этого не требуется вызов внешней функции, просто проверка внутреннего типа.
У меня есть метод с параметром Object o
.
В этом методе я точно знаю, что есть String
в "o", который не является нулевым. Нет необходимости проверять или делать что-то еще. Я должен рассматривать его точно как объект String
.
Просто любопытно - что дешевле - приведите его к String
или используйте Object.toString()
?
Или это то же самое время /cpu -/mem-price?
Обновление:
Метод принимает Object
, потому что это реализация интерфейса. Невозможно изменить тип параметра.
И вообще не может быть null
. Я просто хотел сказать, что мне не нужно проверять его на пустоту или пустоту. В моем случае всегда есть непустая строка.
литье в String дешевле, поскольку для этого не требуется вызов внешней функции, просто проверка внутреннего типа.
Я бы использовал актерский состав. Это подтверждает ваши "знания", что это строка. Если по какой-то причине у вас заканчивается ошибка, и кто-то передает что-то другое, кроме строки, я думаю, что было бы лучше создать исключение (которое будет делать приведение), чем продолжать выполнять с неверными данными.
Согласно Глупые представления производительности: x.toString() vs (String) x
В конце концов результаты на удивление clear: он по крайней мере в два раза быстрее для передачи объекта в строку, чем для вызова Object.toString()
Если вы знаете, что Object o является строкой, я бы сказал, просто передал ее в String и обеспечил ее таким образом. Вызов toString() для объекта, который, как вы знаете, является строкой, может просто добавить путаницу.
Если Object o может быть чем-то другим, кроме String, вам нужно вызвать toString().
Я бы не слишком беспокоился о производительности, если эта операция выполняется даже несколько тысяч раз в секунду - нет ощутимых различий.
Я бы, однако, был обеспокоен "знанием" ввода. У вас есть метод, который принимает Object
, и вы должны рассматривать его как таковой, т.е. Вы не должны знать ничего о параметре, кроме того, что он придерживается интерфейса Object
, который имеет метод toString()
. В этом случае я настоятельно рекомендую использовать этот метод, а не просто что-то делать.
OTOH, если вход всегда либо String
, либо null
, просто измените метод, чтобы принять String
s, и явно проверьте для null
(что вы должны делать в любом случае, когда имеете дело с не-примитивами...)
Не может быть "нулевой строки в o". Если o имеет значение null, он не содержит пустую строку, это просто значение null. Просто сначала проверьте o для null. Если вы произнесете или вызовите ToString() в нуле, вы сработаете.
Если то, что у вас есть в "o" , является строкой, тогда нет большой разницы (вероятно, приведение выполняется быстрее, но это вещь реализации VM/Library).
Если "o" может не быть строкой, но предполагается, что это String, то приведение - это то, что вы хотите (но вы должны заставить метод взять строку вместо объекта).
Если "o" может быть любым типом, тогда вы должны использовать toString, но сначала обязательно проверьте значение null.
void foo(final Object o)
{
final String str;
// without this you would get a class cast exception
// be wary of using instanceof though - it is usually the wrong thing to do
if(o instanceof String)
{
str = (String)o;
}
}
или
void foo(final Object o)
{
final String str;
// if you are 100% sure that o is not null then you can get rid of the else
if(o != null)
{
str = o.toString();
}
}
Я предпочел бы код последнего:
void foo(final Object o)
{
final String str;
if(o == null)
{
throw new IllegalArgumentException("o cannot be null");
}
str = o.toString();
}
Учитывая, что ссылочным типом является Object и все объекты имеют toString(), просто вызывайте object.toString(). String.toString() просто возвращает это.
Мне показалось странным, что приведение было медленнее, чем просмотр vtable, подразумеваемый вызовом tostring.