¿Cuál es más rápido, int a String o String a int?

Esto puede parecer una pregunta bastante básica, para lo cual pido disculpas por adelantado.

Estoy escribiendo una aplicación de Android que utiliza un conjunto de números predefinidos. En este momento estoy trabajando con valores int , pero en algún momento probablemente necesitaré usar float y valores double , también.

Los números se utilizan para dos cosas. Primero, necesito mostrarlos al usuario, para lo cual necesito una String (estoy creando una View personalizada y dibujo la String en una Canvas ). En segundo lugar, necesitaré usarlos en una especie de calculadora, para la cual obviamente necesitan ser int (o float / double ).

Dado que los números son los mismos si se utilizan como String o int , sólo quiero almacenarlos una vez (esto también reducirá los errores si necesito cambiar alguno de ellos, sólo tendré que cambiarlos en un lugar) .

Mi pregunta es: ¿Debo almacenarlos como String o como int ? ¿Es más rápido escribir un int como una String o analizar un int de una String ? Mi intestino me dice que el análisis sintáctico tardaría más tiempo / recursos, por lo que debería almacenarlos como int s. ¿Estoy bien?

En realidad, su intestino puede estar equivocado (y puedo enfatizar puede, ver mis comentarios a continuación sobre la medición). Para convertir una cadena en un entero, se requiere una serie de operaciones de multiplicar / agregar. Para convertir un entero en una cadena se requiere división / módulo. Puede ser que la primera sea más rápida que la segunda.

Pero me gustaría señalar que usted debe medir, no adivinar! El paisaje está lleno de cadáveres de algoritmos que se basan en suposiciones incorrectas.

También quiero señalar que, a menos que su calculadora se espera hacer un gran número de cálculos cada segundo (y estoy hablando de millones si no miles de millones), la diferencia será casi seguramente irrelevante.

En la gran mayoría de las aplicaciones interactivas con el usuario, el 99% de todo el tiempo de la computadora se gasta esperando que el usuario haga algo.

Mi consejo es hacer lo que hace su vida más fácil como desarrollador y preocuparse por el rendimiento si (y sólo si) se convierte en un problema. Y, sólo para aclarar, sugeriría que almacenarlos en forma nativa (no como cadenas) sería más fácil para una calculadora.

Hice una prueba en una matriz de tamaño 1 000 000 de int y String. Sólo cronometré el análisis y los resultados dice:

  • Caso 1, de int a String: 1 000 000 en un promedio de 344ms
  • Caso 2, de String a int: 1 000 000 en un promedio de 140ms

Conclusión, que las tripas estaban mal :)!

Y me uno a los otros diciendo, esto no es lo que va a hacer que su aplicación sea lenta. Mejor concentrarse en hacerlo más sencillo y seguro.

Yo diría que eso no es realmente relevante. Lo que debería importar más es la seguridad de tipo: ya que tiene números int (o float y double ) le obligaría a usar números y no almacenar datos "arbitrarios" (que String permitiría hasta cierto punto).

Lo mejor es hacer una prueba de banco. Escribir dos bucles

  • uno que convierte 100000 unidades de numérico a String
  • uno que convierte 100000 unidades de String a numeric

Y mide el tiempo transcurrido al obtener System.currentTimeMillis () antes y después de cada bucle.

Pero personalmente, si necesitara hacer un cálculo en estos números, los almacenaría en su formato nativo (int o float) y solo los convertiría en String para su visualización. Esto es más una cuestión de diseño y mantenimiento que una cuestión de velocidad de ejecución. Enfocarse en la velocidad de ejecución es a veces contraproducente: para ganar unos pocos μSec nadie se dará cuenta no vale la pena sacrificar el diseño y la robustez (por supuesto, algunos compromisos pueden tener que hacer cuando se trata de ahorrar mucho tiempo de CPU). Esta lectura puede interesarte .

Un ser humano que está usando la calculadora no notará una diferencia de rendimiento, pero como otros han dicho. El uso de cadenas como su representación interna es una mala idea, ya que no recibe la seguridad de tipo en ese caso.

Lo más probable es que tenga problemas de mantenimiento más adelante si decide usar cadenas.

Es una práctica de diseño mejor que la vista se muestre al usuario que se deriva de los datos subyacentes, en lugar de al revés – en algún momento puede decidir hacer la calculadora utilizando sus propias funciones de dibujo o imágenes fijas y tener sus datos como cuerdas sería un dolor aquí.

Dicho esto, ninguna de estas operaciones requiere mucho tiempo usando hardware moderno.

Parsing es una cosa lenta, la impresión de un número no lo es. La representación interna como número le permite calcular, que es probablemente lo que se pretende d con sus números. Almacenar números como, bueno, números (ints, floats, decimals) también ocupa menos espacio que sus representaciones de cadena, así que … probablemente querrá ir con almacenarlos como ints, floats, o lo que sea.

Usted está escribiendo una aplicación para dispositivos móviles, donde el consumo de memoria es un gran negocio.

Almacenar un int es barato, almacenar una String es caro. Ir a int .

Editar: más explicación. Almacenar un int entre -2^31 y 2^31-1 cuesta 32 bits. No importa cuál sea el número. Almacenarla en una String es de 16 bits por dígito en su representación base 10.

  • Necesidad de manejar el clic de la clase NON-Activity (.java)
  • Problema con strings.xml ... no puede pasar R.string.foo como CharSequence
  • Cómo recuperar y modificar el contenido HTML de WebView con Http Post
  • LibGDX pausa en funcionamiento durante unos segundos
  • Error de actualización La cadena de consulta de URL no debe tener el bloque de reemplazo
  • El valor no se actualiza onProgress para Range-seek-bar
  • Sabores de productos dependencia Android de Gradle
  • Cómo obtener los elementos seleccionados de un elemento de opción múltiple en un Alert.Builder?
  • ¿Cómo tratar con DeadObjectException en el servicio fallecido?
  • Cómo agregar niños a childnodes mediante el documento jsoup
  • El envío de entrada de ANR excedió el tiempo de espera en Android 4.4
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.