c# - online - ¿Es seguro asumir generalmente que toString() tiene un costo bajo?

java vs c# 2018 (17)

¿Generalmente asume que toString () en cualquier objeto dado tiene un costo bajo? Hago.

¿Por qué harías eso? Perfile su código si se encuentra con problemas de rendimiento; le ahorrará mucho tiempo trabajando con suposiciones incorrectas.

¿Generalmente asume que toString () en cualquier objeto dado tiene un bajo costo (es decir, para el registro)? Hago. ¿Es esa suposición válida? Si tiene un costo elevado, ¿debería cambiarse normalmente? ¿Cuáles son las razones válidas para hacer un método toString () con un alto costo? La única vez que me preocupan los costos de String es cuando sé que está en algún tipo de colección con muchos miembros. De: http://jamesjava.blogspot.com/2007/08/tostring-cost.html

Actualización: Otra forma de decirlo es: ¿normalmente se fija en el costo de llamar a String en cualquier clase antes de llamarlo?

Como generalmente solo llamo a String () sobre métodos y clases que he escrito yo mismo y sobreescribo el método base, generalmente sé cuál es el costo antes de tiempo. La única vez que uso toString () es el manejo de errores o la depuración cuando la velocidad no es de la misma importancia.

Creo que la pregunta tiene un defecto. Ni siquiera asumiría que toString () imprimirá una pieza útil de datos. Entonces, si comienzas con esa suposición, sabes que debes verificarla antes de llamarla y puedes evaluar su ''costo'' caso por caso.

Dado que pones "en general" en tu pregunta, diría que sí. Para la mayoría de los objetos, no habrá una costosa sobrecarga de ToString. Definitivamente puede haber, pero generalmente no habrá.

El título de su pregunta utiliza las palabras contradictorias "seguro" y "en general". Entonces, aunque en los comentarios parezca que está enfatizando el caso general, para el cual la respuesta es probablemente "sí, generalmente no es un problema", mucha gente está viendo "seguro" y por lo tanto están respondiendo "No, porque hay un riesgo de rendimiento arbitrariamente malo "o" No, porque si quiere estar ''seguro'' con una pregunta de rendimiento, debe hacer un perfil ".

En general, considero toString () low cost cuando lo uso en objetos simples, como un entero o una estructura muy simple. Sin embargo, cuando se aplica a objetos complejos, toString () es un poco de disparate. Hay dos razones para esto. En primer lugar, los objetos complejos tienden a contener otros objetos, por lo que una sola llamada a toString () puede formar una cascada en muchas llamadas a toString () en otros objetos, además del principio de concatenación de todos esos resultados. En segundo lugar, no existe un "estándar" para convertir objetos complejos en cadenas. Una llamada a toString () puede generar una sola línea de valores separados por comas; otra una forma mucho más verbosa. Solo al verificarlo usted mismo puede saberlo.

Así que mi regla es que toString () en objetos simples es generalmente seguro, pero en objetos complejos es sospechoso hasta que se compruebe.

Hay una respuesta fácil a esta, que escuché por primera vez en una discusión sobre la reflexión: "si tiene que preguntar, no puede pagarlo".

Básicamente, si necesita ToString () de objetos grandes en el funcionamiento diario de su programa, entonces su programa está loco. Incluso si necesita ToString () un número entero para cualquier momento crítico, su programa está loco, porque obviamente está usando una cadena donde un entero haría.

ToString () para mensajes de registro está automáticamente bien, porque el registro ya es costoso. Si su programa es demasiado lento, baje el nivel de registro. En realidad, no importa lo lento que sea generar realmente los mensajes de depuración, siempre que pueda elegir no generarlos. (Nota: su infraestructura de registro debe llamar a ToString () y solo cuando se supone que se va a imprimir el mensaje de registro. No lo toque ToString () manualmente en el camino a la infraestructura de registro, o tendrá que pagar el precio incluso ¡Si el nivel de registro es bajo y no lo va a imprimir después de todo! Consulte http://www.colijn.ca/~caffeine/?m=200708#16 para obtener más información al respecto).

La mejor manera de averiguarlo es perfilar tu código. Sin embargo, en lugar de preocuparse de que una función en particular tenga una sobrecarga, es (generalmente) mejor preocuparse por la corrección de su aplicación y luego hacer perfiles de rendimiento en ella (pero tenga cuidado con el uso en el mundo real y la configuración de la prueba puede diferir radicalmente ) Como resultado, los programadores generalmente adivinan incorrectamente lo que es realmente lento en su aplicación y a menudo pasan mucho tiempo optimizando cosas que no necesitan optimización (eliminando ese triple ciclo anidado que solo consume 0.01% del tiempo de su aplicación es probablemente un desperdicio).

Afortunadamente, hay muchos analizadores de código abierto para Java .

Mi pensamiento es:

Sí en objetos de biblioteca estándar

No en objetos no estándar a menos que tengas el código fuente frente a ti y puedas verificarlo.

Mi respuesta pragmática sería: sí, siempre asumes que una llamada aString () es barata, a menos que hagas una gran cantidad de ellas. Por un lado, es extremadamente improbable que un método toString () sea costoso y, por otro lado, es extremadamente improbable que tenga problemas si no es así. Por lo general, no me preocupo por problemas como estos, porque hay demasiados y no obtendrás ningún código si lo haces;).

Si se encuentra con problemas de rendimiento, todo está abierto, incluido el rendimiento de toString () y, como sugiere Shog9, debería simplemente crear un perfil del código. Los Puzzlers de Java muestran que incluso Sun escribió algunos constructores bastante desagradables y métodos toString () en sus JDK.

Posiblemente, el mayor costo con el encadenamiento naive toString () es agregar todas esas cadenas. Si desea generar cadenas de gran tamaño, debe utilizar una representación subyacente que admita un anexo eficiente. Si sabe que el apéndice es eficiente, entonces toString () probablemente tenga un costo relativamente bajo.

Por ejemplo, en Java, StringBuilder preasignará un espacio de modo que una cierta cantidad de cadenas agregadas tome tiempo lineal. Se reasignará cuando te quedes sin espacio.

En general, si desea agregar secuencias de cosas y, por cualquier razón, no desea hacer algo similar, puede usar listas de diferencias . Estos soportan el tiempo lineal que se agrega al girar la secuencia que se agrega a la composición de la función.

Siempre anularé a String para incluir lo que sea que necesite para solucionar problemas. Normalmente el desarrollador debe usarlo llamando al método toString o llamando a otra clase (println, logging, etc.).

toString () se usa para representar un objeto como una Cadena. Entonces, si necesita un código de ejecución lenta para crear una representación de un objeto, debe tener mucho cuidado y una buena razón para hacerlo. La depuración sería la única en la que puedo pensar que es aceptable una ejecución lenta en String.

La biblioteca estándar de Java parece haber sido escrita con la intención de mantener el costo de las llamadas aString muy bajo. Por ejemplo, las matrices y colecciones Java tienen métodos toString que no iteran sobre sus contenidos; para obtener una buena representación de cadena de estos objetos, debe usar Arrays.toString o Collections.toString del paquete java.util .

De manera similar, incluso los objetos con métodos iguales caros tienen llamadas de bajo costo a String. Por ejemplo, la clase java.net.URL tiene un método igual que hace uso de una conexión a Internet para determinar si dos URL son realmente iguales, pero todavía tiene un método simple y de tiempo constante toString.

Así que sí, las llamadas económicas a String son la norma, y a menos que use algún extraño paquete de terceros que rompa con la convención, no debe preocuparse de que esto tome mucho tiempo.

Por supuesto, no deberías preocuparte por el rendimiento hasta que te encuentres en una situación en la que tu programa demore demasiado, e incluso entonces deberías utilizar un generador de perfiles para averiguar qué es lo que lleva más tiempo en lugar de preocuparte por este tipo de cosas. de tiempo.

Evitaría usar toString () en objetos que no sean los tipos básicos. toString () puede no mostrar nada útil. Puede iterar sobre todas las variables miembro e imprimirlas. Puede cargar algo que aún no está cargado. Dependiendo de lo que planeas hacer con esa cadena, deberías considerar no construirla.

Normalmente hay algunas razones por las que utiliza toString (): el inicio de sesión / depuración es probablemente el más común para los objetos aleatorios; la visualización es común para ciertos objetos (como números). Para iniciar sesión, haría algo como

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

Esto hace dos cosas: 1. Impide construir la cadena y 2. Evita la adición innecesaria de cadenas si el mensaje no se registra.

En general, no reviso cada implementación. Sin embargo, si veo una dependencia en los recursos comunes de Apache, las alarmas suenan y miro la implementación más de cerca para asegurarme de que no estén usando ToStringBuilder u otras atrocidades.

No, no es. Como ToString () puede ser sobrecargado por cualquier persona, puede hacer lo que quiera. Es una suposición razonable que ToString () DEBE tener un costo bajo, pero si ToString () accede a las propiedades que hacen "carga diferida" de datos, incluso puede golpear una base de datos dentro de su ToString ().