¿Debo comprimir objetos C-en-memoria para un mejor rendimiento?

Tengo una aplicación (C#, WPF) que muestra muchos cuadros financieros con transmisión de datos en vivo desde el servidor. Los datos que se recopilan en la memoria pueden llegar a ser un poco grandes y no quiero guardar ningún dato en el disco.¿Debo comprimir objetos C-en-memoria para un mejor rendimiento?

Como los datos históricos en sí no cambian, pero solo se agregan a, ¿tiene sentido mantener esos datos (que se almacenan en un objeto de colección) en algún formato comprimido?

¿Es posible y alguien puede recomendar una buena práctica si es así?

ACTUALIZACIÓN

Algunas notas sobre el rendimiento y la solución de compromiso: Soy consciente de que la compresión se sumará un retraso acceder a los datos, pero, el usuario sólo necesita actualizaciones rápidas sobre nuevos datos que llegan. Al acceder a los datos que ya se procesaron (por ejemplo, para estudiarlos o reproducirlos), no necesita una respuesta rápida.

Fuente

2011-03-31 Saul

Cuando dices "grande", ¿qué tan grande quieres decir? – HABJAN

@HABJAN podría ser el décimo de MB o 100º, ¿por qué? Básicamente no es un "problema" manejar esta cantidad de datos, pero quiero mantener la huella de memoria de la aplicación lo más pequeña posible. – Saul

Recomiendo usar una solución industrial. Un ejemplo es la base de datos KDB que es genial como almacenamiento en memoria. – Andrey

Comprimir y descomprimir hará que su aplicación sea más lenta, por lo que para el rendimiento (velocidad) no es una buena opción. La compresión solo es útil cuando le preocupa la memoria disponible. Puede ser más fácil almacenar/intercambiar los datos en una carpeta temporal.

La clave del rendimiento es la medición. Solo tome medidas cuando haya crujido los números.

Fuente

2011-03-31 17:46:44

@Erno pero una vez que se muestra, apenas hay acceso a los datos antiguos, ¿cuál es el precio de rendimiento aquí? – Saul

Usted sugirió comprimir los datos en la memoria. Para visualizar datos comprimidos, deberá descomprimirlo. Eso lleva tiempo. Seguro que cuando lo haya mostrado y ya no necesite acceder, podría comprimirlo, pero ¿por qué no deshacerse de él simplemente porque ya no lo necesita? Nuevamente mida primero, luego comience a hacer los cálculos y pida consejo. Hasta entonces solo estamos adivinando. –

@Erno Gracias, voy a medir, actualmente sé de este problema de otras aplicaciones. Para la discusión: no quiero desecharlo ya que necesitaré acceder a él, y no quiero volver a descargarlo. Cuando accedo a él, puedo pagar el precio del retraso (pero no el ancho de banda). Pensé en renderizar el gráfico una vez, comprimir los datos, y luego simplemente actualizar el gráfico con la llegada de nuevos datos. – Saul

Comprimir los datos tiene ventajas en términos de uso de memoria, pero desventajas en términos de hacer que los datos sean inutilizables (tendrá que descomprimirlo para usarlo de nuevo), así como tomar CPU adicional.

El punto de equilibrio en el que esto sería beneficioso es difícil de saber sin mucha más información, depende de usted. Sin embargo, si no está utilizando estos datos viejos y obsoletos, puede ser mejor simplemente descartarlos (es decir, dejarlos fuera del alcance/dejar de almacenarlos) en lugar de comprimirlos.

La compresión se puede hacer a través de las clases en System.IO.Compression, y es bastante fácil. Estas clases, en general, no funcionan muy bien, sin embargo, por lo que es posible que también desee considerar una alternativa de terceros, como DotNetZip.

Fuente

2011-03-31 17:47:34

Cuando escribí a Erno, utilizaré esta información de vez en cuando, en momentos que no requieren una respuesta rápida. No quiero tirarlo porque entonces tendré que descargarlo cada vez y el ancho de banda es más caro. – Saul

@Saul: Entonces, un caché basado en disco parece una opción potencialmente apropiada. Es poco probable que la compresión le ahorre una tonelada de memoria, pero tendrá un costo de CPU bastante alto ... –

Si está utilizando .NET 4.0, le recomiendo que almacene los datos históricos utilizando los archivos asignados de memoria. El VMM puede moverse a través de archivos en el disco sin que sea necesario que lea un archivo completo para obtener datos. –

Es una compensación entre el rendimiento y la huella de memoria y también depende de las estructuras de datos que está utilizando. La compresión "genérica" (es decir, gzip, codificación de longitud de ejecución, etc.) no tiene sentido para muchos tipos de datos.

Un enfoque que podría ser de aplicación a que se está recuperando una estructura de datos más apropiado que optimiza el consumo de memoria - es decir, para el gráfico es lo que realmente tiene que almacenar precios de las acciones independientes o se puede vivir con sólo el almacenamiento de valores delta? Si lo posterior es cierto, probablemente podría reducir los bits necesarios para cada punto de datos. Otra cosa es volver a generar los patrones que se necesitan en todos los gráficos. ¿Podría factorizarlos en un objeto separado utilizado por todos los gráficos y, por lo tanto, solo crear una instancia una vez?

Fuente

2011-03-31 17:49:24 BrokenGlass

Si busca un mejor rendimiento, la compresión no es el camino a seguir. Siempre que el host del cliente tenga suficiente memoria para manejar los datos, mantener los datos descomprimidos generará el máximo rendimiento. La compresión de los datos requerirá algoritmos de compresión y compresión para ejecutar cada vez que se acceda a los datos.

Si se está quedando sin memoria en el host del cliente, entonces se encontrará en una situación en la que se verá obligado a comprimir los datos almacenados.Sin embargo, tenga en cuenta que esto solo ahorrará memoria cuando los datos estén comprimidos y Garbage Collection haya recopilado los objetos en memoria que no están comprimidos. Debido a que los datos deberán ser descomprimidos para ser utilizados, esto nunca proporcionará una solución para maximizar la memoria RAM del cliente.

Teniendo todo esto en cuenta, .NET proporciona el espacio de nombres System.IO.Compression para realizar la compresión gzip. Si necesita compresión, comenzaría buscando allí.

Fuente

2011-03-31 17:50:13

Si está dispuesto a codificarlo usted mismo, existen estructuras de datos eficientes en el uso del espacio que no requieren descodificación/descompresión para su uso. Steve Hanov describes Succinct Data Structures en su última publicación de blog. Su ejemplo es un trie sucinto pero no hay nada que te impida representar otros objetos y estructuras. Él cita varias implementaciones alternativas.

Obviamente, esta no es una solución lista para usar. Tendrás que decidir si vale la pena el esfuerzo de construir y probar una representación sucinta.

Fuente

2011-03-31 18:19:16

¿Debo comprimir objetos C-en-memoria para un mejor rendimiento?

Respuesta

Cuestiones relacionadas