¿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.
- Uso del selector de dispositivos Android Bluetooth
- Sockets, Threads y Servicios en android, ¿cómo hacerlos trabajar juntos?
- Android: Múltiples vistas de los niños para una vista personalizada con un diseño existente
- Adaptador de ListView personalizado lanza UnsupportedOperationException
- Cómo convertir int a typedarray Android
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?
- Mejor manera de analizar la Biblia en Android
- Cómo obtener la dirección IP directa de WiFi de mi dispositivo
- Cómo analizar el análisis de json Usando GSON en android
- android.support.v4.app.FragmentTransaction necesario
- Cómo compartir el diseño IDE en IntelliJ IDEA?
- Ajustar un ImageView (y su src) al ancho de diseño y hacer su altura proporcional
- Cambiar la listaVer el color seleccionado en Android
- Multi-nivel ExpandableListView en Android
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.
- android usando setlistadapter () sin extender listactivity
- Field.getGenericType () devuelve la instancia de java.lang.Class en lugar de Type