Forma más eficiente para probar el tipo de objeto

votos
17

Tengo valores almacenados como cadenas en a DataTabledonde cada valor podría representar realmente un int, doubleo string(todos se convirtieron en cadenas durante un proceso de importación desde un origen de datos externo). Necesito probar y ver qué tipo es cada valor realmente.

¿Qué es más eficiente para la aplicación (o no hay diferencia práctica)?

  1. Intenta convertir a int(y luego double). Si la conversión funciona, la devolución true. Si se lanza una excepción, regresa false.
  2. Expresiones regulares diseñadas para coincidir con el patrón de una intodouble
  3. Algún otro método?
Publicado el 05/08/2008 a las 08:49
fuente por usuario
En otros idiomas...                            


5 respuestas

votos
9

Utilizaría double.TryParse, tiene beneficios de rendimiento.

Respondida el 05/08/2008 a las 08:54
fuente por usuario

votos
6

Yo diría que no te preocupes tanto por ese micro rendimiento. Es mucho mejor hacer que algo funcione, y luego hacerlo lo más claro y conciso y fácil de leer posible. Lo peor que puedes hacer es sacrificar la legibilidad por una cantidad insignificante de rendimiento.

Al final, la mejor forma de lidiar con los problemas de rendimiento es guardarlos cuando tenga datos que indiquen que hay un problema de rendimiento real ... de lo contrario perderá mucho tiempo micro-optimizando y de hecho causará mayores costos de mantenimiento para mas tarde.

Si encuentra que esta situación de análisis es realmente el cuello de botella en su aplicación, ENTONCES es el momento de intentar averiguar cuál es la forma más rápida de resolver el problema. Creo que Jeff (y muchos otros) han escrito mucho sobre este tipo de cosas.

Respondida el 05/08/2008 a las 09:04
fuente por usuario

votos
5

El problema que tienes es que podría haber situaciones en las que la respuesta podría ser de los tres tipos.

3 podría ser un int, un doble o una cadena!

Depende de lo que trates de hacer y cuán importante es que sean de un tipo particular. Lo mejor sería dejarlos tal como están, siempre que sea posible o, alternativamente, usar un método para marcar cada uno (si tiene control de la fuente de la cadena original).

Respondida el 23/09/2008 a las 22:38
fuente por usuario

votos
5

Obtendrá diferentes resultados para los diferentes métodos según compile con optimizaciones. Básicamente tienes algunas opciones:

object o;

//checking with is
o is int

//check type
o.GetType() != typeof( int )

//cast and catch exception
try{ int j = (int) o; } 
catch {}

//use the tryparse
int.TryParse( Convert.ToString( o ), out j )

Puede configurar fácilmente una aplicación de consola que intente cada una de estas 10.000 veces y devuelva la duración de cada una (pruebe cuando o es un int y cuando se trata de otra cosa).

El try-catchmétodo es el más rápido si el objeto contiene un int, y de lejos el más lento si no (incluso más lento que GetType). int.TryParsees bastante rápido si tiene una cadena, pero si tiene un objeto desconocido es más lento.

Curiosamente, con .Net 3.5 y las optimizaciones activadas, la o is intverificación toma el mismo tiempo que try-catchcuando o en realidad es un int. o is intes solo un poco más lento si o realmente es otra cosa.

Curiosamente, FxCop lanzará advertencias si haces algo como:

if( o is int )
    int j = (int) o;

Pero creo que es un error en FxCop: no sabe que int es un tipo de valor y te recomienda utilizarlo o as inten su lugar.

Si su entrada es siempre una cadena int.TryParsees mejor, de lo contrario, el isoperador es más rápido.

Como tiene una cadena, miraría si necesita saber que es un int, en lugar de un doble. Si se int.TryParseaprueba, también lo hará, double.TryParsepor lo que podría obtenerse la mitad del número de cheques: devuelva el doble o la cuerda, y el doble cuando espera un int.

Respondida el 10/08/2008 a las 18:43
fuente por usuario

votos
3

Yo personalmente usaría int.tryparse, luego double.tryparse. El rendimiento en esos métodos es bastante rápido. Ambos devuelven un booleano. Si ambas fallas, entonces tienes una cadena, por la forma en que definiste tus datos.

Respondida el 05/08/2008 a las 09:02
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more