una - .Net 2.0-¿Qué tan eficientes son las listas genéricas?
tipos de genericos (10)
Creo que la cosa de los dos procesos puede ser excesiva; además, la comunicación entre procesos probablemente tendrá cierta lentitud (aunque nunca he probado tal cosa, por lo tanto, tome mi opinión como un grano de sal). Trabajo en una aplicación basada en datos donde cada unidad de datos es pequeña, pero podemos tener más de mil millones de unidades de datos en un momento dado. El método que usamos es básicamente:
- Todo reside en el disco, no importa qué
- Los datos están bloqueados en "fragmentos"; cada pedazo sabe cuándo fue visitado por última vez
- Los trozos se arrastran desde el disco a la memoria cuando se necesitan
- Un hilo de baja prioridad monitorea el uso de la memoria y elimina las cosas menos usadas recientemente
En otras palabras, es un esquema de almacenamiento en caché casero. El beneficio es que puede controlar con precisión exacta qué datos hay en la memoria, lo que no puede hacer si confía en el esquema de paginación del sistema operativo. Si alguna variable de uso común termina mezclada con sus datos en una página, esa página se golpeará repetidamente e impedirá que vaya al disco. Si diseñas en tu aplicación una adaptación que algunas solicitudes de datos tomarán más tiempo que otras, entonces esto funcionará bastante bien. Particularmente si sabes qué trozos necesitarás con anticipación (no es así).
Tenga en cuenta que todo en una aplicación .NET tiene que caber dentro de 2 GB de memoria, y debido a la forma en que funciona el GC y la sobrecarga de su aplicación, es probable que tenga algo menos que eso para trabajar.
Para espiar exactamente cómo es su montón y quién está asignando, use el generador de perfiles CLR : http://www.microsoft.com/downloads/details.aspx?familyid=86ce6052-d7f4-4aeb-9b7a-94635beebdda&displaylang=en
Estoy creando una aplicación que contiene montones de cargas de datos de usuario en la memoria, y en su mayor parte lo mantiene todo en estructuras List <T> (y algún Dictionary <T, T> cuando necesito buscar).
Y me pregunto ...
¿Qué tan eficientes son las listas? ¿Cuánta memoria sobrecarga tengo para cada uno de ellos? (es decir, espacio de memoria además de lo que tomarían los objetos que contienen) ¿Cuánto de una multa debo pagar cada vez que instalo una nueva?
¿Hay una manera más eficiente?
Los diccionarios son solo HashTables, ¿verdad? ¿O son ellos una estructura de datos menos eficiente?
Me gustaría utilizar matrices, pero tengo el problema típico de agregar y quitar cosas todo el tiempo de ellos, por lo que tener que crecer / reducirlos sería un dolor.
¿Alguna idea / sugerencia?
Editar: conozco mis estructuras básicas de datos 101, y por qué una lista vinculada es mejor para agregar / eliminar, y una tabla Hash es mejor para el acceso aleatorio.
Estoy más que nada preocupado por las idiosincracias de .Net. Cuánta memoria desperdicia cada una de estas estructuras, por ejemplo. Y el tiempo perdido al inicializar / matarlos.
Cosas como, por ejemplo, si toma mucho tiempo para instancia / GC a List, pero no mucho para borrarlo, tal vez debería mantener un pequeño grupo de Listas esperándome, borrarlas y enviarlas al grupo cuando haya terminado, en lugar de simplemente desreferenciarlos.
O bien, si las Hashtables son más rápidas para el acceso pero desperdician mucha memoria, tal vez prefiera usar las Listas y recorrerlas, para conteos pequeños de elementos.
Y también me gustaría centrarme en el uso de la memoria, ya que mi aplicación es intensamente intensiva en memoria (creo que es similar a una memoria) ... ¿Alguien sabe dónde puedo encontrar esa información?
El objeto LinkedList tomaría menos tiempo para agregar y quitar debido a la naturaleza de las listas vinculadas. Cuando agrega un elemento, no tiene que cambiar el tamaño de una matriz como lo hace una lista normal. Aparte de esa mejora, sospecho que LinkedList tendrá el mismo rendimiento que una lista normal.
Ver esto en Wikipedia: Listas vinculadas vs. matrices
La .Net List no usa una lista vinculada. Es una matriz, comienza con 4 posiciones por defecto y creo que duplica su tamaño a medida que agrega cosas. Entonces el rendimiento puede variar un poco dependiendo de cómo lo use.
Si usas VS 2008 ejecuta el generador de perfiles antes de llegar demasiado lejos en este agujero de rata. Cuando empezamos a ver realmente dónde estábamos perdiendo tiempo, no pasó mucho tiempo para que descubriéramos que el debate sobre los puntos más finos de las listas enlazadas realmente no importaba.
Las listas son matrices debajo, por lo que el rendimiento de agregar un elemento, a menos que sea al final, será muy costoso.
De lo contrario, serán básicamente tan rápidos como una matriz.
List usa una matriz internamente y Dictionary usa una tabla hash.
Son más rápidos que las antiguas clases no genéricas ArrayList y HashTable porque no tiene el costo de convertir todo en / desde objetos (boxeo, unboxing y verificación de tipos) y porque MS los optimizó mejor que las clases antiguas.
No movería un dedo hasta que haya algún problema de rendimiento y un perfilador demostró que lo era. Entonces tendrás un problema definitivo para resolver y será mucho más fácil.
Si le preocupa el uso de memoria, la verdadera clave es almacenar su matriz en el disco y asignar solo las partes que necesita en la memoria en ese momento.
La clave es usar FILE_FLAG_NO_BUFFERING y siempre leer / escribir exactamente el valor de un sector de datos.
Si necesita eficiencia para insertar o eliminar lugares aleatorios en la lista, hay una estructura de datos LinkedList: el artículo de MSDN proporciona detalles. Obviamente, al ser una lista vinculada, el acceso aleatorio no es eficiente.
Si realmente desea ver todos los detalles sangrientos de cómo se implementan List <> y Dictionary <,>, use el maravillosamente útil .NET Reflector .
Consulte también la documentación de la excelente Biblioteca de colecciones genéricas de C5 , que tiene implementaciones muy buenas de varios tipos de colecciones que faltan en el BCL.
Tal vez deberías considerar el uso de algún tipo de base de datos en memoria si tienes tantos datos que deben guardarse en la memoria,