2010-08-19 18 views
5

tengo un diccionario de 10000 productos/color/tamaño combinaciones que he creado con algo como:¿Velocidad de búsqueda del valor del diccionario .NET por clave?

AllRecords = DB.ProductColourSizes _ 
      .ToDictionary(function(b) String.Format("{0}_{1}_{2}", _ 
      b.ProductCode, b.ColourCode, b.SizeCode)) 

lo tanto, un ejemplo de teclas es como "13AI_GRS_M"

tengo que sincronizar mi base de datos con el ERP de la compañía cada 30 minutos, y para cada combinación de Color/Tamaño necesito usar este diccionario para agregar, editar o borrar registros. Ojalá hubieran suministrado números de identificación.

No sé cómo funciona el diccionario internamente. ¿Qué tan rápido es .NET para encontrar el valor correcto basado en tal clave? ¿Debo ordenar la consulta de la base de datos, o .NET tiene alguna otra forma de identificar la clave?

¿O debería convertirlo en una lista y usar un diccionario para identificar el índice correcto? O de otra manera completamente?

También uso diccionarios estáticos de esta manera en toda la aplicación del sitio web, por lo que aprender una mejor manera de hacerlo tendría una gran influencia.

Muchas gracias, Steve

+0

Muchas gracias por sus respuestas. Soy nuevo en el sitio, por lo que aún no aprendí la etiqueta, pero me di cuenta de que hice una pregunta en la que 5 personas señalaron amablemente que el código "está bien" por varias razones. ¿Debo marcarlos todos como útiles? Gracias de nuevo. Steve –

+0

Solo puedes marcar 1 como 'aceptado'. Solo usa tu juicio. –

Respuesta

3

Por lo que estás haciendo el diccionario es perfecto.

El tiempo de recuperación de claves para los artículos en un diccionario es maldita rápido, pero en última instancia depende de la función de código hash de la clave (en su caso string.GetHashCode()).

Estás de suerte, porque la función GetHashCode() de la cadena .Net es muy buena. Si obtiene un código de hash Choque, .Net llamará al método Equals en el objeto, y lo que garantiza la singularidad.

Tenemos diccionarios con cientos de miles de artículos, y los tiempos de búsqueda son insignificantes.

La clasificación del conjunto de resultados de la base de datos no será de ninguna utilidad en este caso.

Espero que esto ayude.

1

Diccionarios se hacen para buscar cosas, por lo que quedarse con eso. El principal problema para el tipo de clave es que debe tener un buen código Hash (bien distribuido).

Puede escribir su propio KeyClass con los códigos ProductCode, ColourCode y SizeCode, pero luego tendrá que sobrecargar los miembros GetHashCode y Equals (y relacionados). Y será bastante difícil mejorar el GethashCode of System.String, y es bastante fácil cometer errores.

Entonces, no te molestes. Su cadena clave se ve bien.

Y si quiere optimizar, primero haga un perfil para ver dónde están sus problemas.

+0

Gracias por señalarme hacia un área de .NET que no conocía ... ¡algo más que investigar! –

+1

Exactamente, no se preocupe demasiado por el rendimiento hasta que sea un problema real y luego identifíquelo con un generador de perfiles, a menudo no es donde cree que está. –

1

Encontrar un valor por clave es muy rápido y usar un diccionario parece ser absolutamente apropiado. La clave que crees también me parece bien. Preseleccionar la base de datos no tiene ningún sentido, el diccionario no depende de esto.

2

¿Qué tan rápido es .NET en encontrar el valor correcto en base a dicha clave?

La complejidad de recuperar el valor de una llave está cerca de O (1) according to MSDN, por lo que es bastante rápido ...

También desde MSDN:

La velocidad de recuperación depende sobre la calidad del algoritmo hash del tipo especificado para TKey.

Si utiliza una cadena como la clave, que debe estar bien, ya que podemos suponer que la clase String utiliza un algoritmo de hash eficiente ...

+0

Thomas, se disculpa por ser pedante, pero que una operación tiene baja complejidad, seguramente no significa que sea intrínsecamente rápida. Será más rápido que una operación con alta complejidad, pero si el algoritmo subyacente es complejo, la notación O grande puede ser baja, pero la operación aún puede ser lenta. ¿O estoy hablando de mi culo? (No soy un experto en el Big O) –

+0

Tiene razón, la complejidad no es lo único a tener en cuenta, pero la complejidad no constante tendría un impacto importante en la velocidad de recuperación real a medida que el diccionario crezca. Solo puede ser tan rápido porque la complejidad es O (1) –

+0

Empecé a programar con los lenguajes de nivel relativamente alto y nunca tuve que preocuparme por los algoritmos de clasificación. Estoy contento de no tener que hacerlo ahora. Gracias por tus respuestas. –

0

Yo uso este 'patrón' con bastante frecuencia, si no puede obtener consultas SQL (especialmente en SQL CE) para ejecutar lo suficientemente rápido.

Es posible que también desee ver la función ToLookup, ya que la considero más conveniente en la mayoría de los casos. Las velocidades de búsqueda no se ven afectadas, utiliza un diccionario asignado a las colecciones.

+0

ToLookup() también ayudará inmensamente en el futuro, gracias. –

Cuestiones relacionadas