2012-03-02 9 views
19

¿Existen reglas genéricas a seguir para descubrir la causa cuando un programa compilado por GHC gasta demasiado tiempo en la recolección de basura? ¿Y qué se consideraría generalmente demasiado? Por ejemplo, en general, ¿el 60% de productividad es aceptable o es una indicación de que algo probablemente esté mal con el código?Asesoramiento genérico sobre la reducción del tiempo de GC en GHC

+0

Para reducir el GC, primero puede usar el perfil de GHC para rastrear qué código es el que más asigna. –

+2

Asigne menos, y obtendrá menos GC. En general, creo que el 25% de GC es aceptable, más alto que eso y empiezo a buscar maneras de reducir la asignación. – augustss

+1

A menudo, ejecutar el programa con "+ RTS -H" ayuda mucho. Además, compila con -O2. – aleator

Respuesta

10

He aquí una lista rápida y muy incompleta:

  1. de prueba y de referencia. Una de las pocas debilidades de Haskell es la dificultad para predecir los costos de tiempo y espacio. Si no tiene datos de prueba, no tiene nada.
  2. Usa mejores algoritmos. Esto suena demasiado simple, pero la optimización de algoritmos ineficientes es como rapear s ** t en oro.
  3. Estratégicamente hacer que algunos datos sean más estrictos. Prueba y punto de referencia! El objetivo es almacenar el valor de WHNF físicamente más pequeño en lugar del valor que lo produce, limpiando así más basura en el primer pase más eficiente. busca funciones complicadas que producen datos simples.
  4. Estratégicamente hacer que algunos datos sean menos estrictos. Prueba y punto de referencia! El objetivo es retrasar la producción de una gran cantidad de datos hasta justo antes de que se use y se descarte, con lo que se limpiará más basura en el primer pase más eficiente. Busque funciones simples que producen grandes datos complejos. Ver también comonads.
  5. Haga un uso estratégico de las matrices y los tipos sin caja, en particular, vea # 2. con respecto a la mónada ST. Prueba y punto de referencia! Todos estos encajan datos más crudos en una memoria más pequeña y compacta. Hay menos basura para recoger.
  6. Fiddle con la configuración RTS (específica de ghc). Prueba y punto de referencia! El objetivo es "igualar la impedancia" del GC con las necesidades de memoria de su programa. Me pierdo aún más aquí, luego en 1-5, así que pregúntales a los expertos sobre este.

La mejor recolección de basura tiene una premisa bastante simple: cree menos basura, recójala antes, produzca menos asignaciones de memoria/desasignación. Cualquier cosa que pueda hacer que pueda resultar en uno de estos tres efectos vale la pena. Prueba y punto de referencia!

+1

+1 para establecer una conexión entre la optimización del algoritmo y el tratamiento de la materia fecal.Poner lápiz labial en el cerdo ahora está envejeciendo, eh :) – Sal

Cuestiones relacionadas