2009-08-25 12 views
16

¿Cómo se puede disponer efectivamente de un objeto StringBuilder? Si un usuario genera múltiples informes en una sola sesión, mi aplicación termina usando una gran cantidad de memoria.Cómo deshacerse de un objeto StringBuilder

que he leído en algunos sitios en línea que el seguimiento puede ayudar:

StringBuilder sb = new StringBuilder(1000000); 

// loop goes here adding lots of stuff to sb 

exampleObject.Text = sb.ToString(); 

sb.Length = 0; 

¿La última línea realmente pueden ayudar? ¿Alguna otra forma de lidiar con esto?

NB: Esto realmente no impide que mis usuarios continúen utilizando la aplicación. Me pregunto si hay alguna manera de evitar el uso de memoria redundante.

+2

sacar el 1000000 podría ayudar – David

+3

¿Cómo? La asignación previa de memoria ayudó mucho. Permitir que StringBuilder cambiara el tamaño constantemente estaba ralentizando bastante las cosas. – Druid

Respuesta

33

No, un StringBuilder es un recurso puramente administrado. Debería deshacerse de todas las referencias a él. Todo lo demás es atendido por el recolector de basura:

StringBuilder sb = ...; 
// ... do work 
sb = null; // or simply let it go out of scope. 

En .NET, no hay determinista delete (como C++, donde liberar la memoria asignada a un solo objeto.) Sólo GC puede liberar memoria. Al perder todas las referencias a un objeto, permitirá que GC pueda desasignar el objeto si así lo desea. Puede forzar una recolección de basura llamando al método System.GC.Collect. Sin embargo, no se recomienda manipular con GC a menos que realmente sepa lo que está haciendo. GC es inteligente. Raramente es beneficioso forzarlo.

+1

agregar un GC.Collect() es perfectamente válido si la utilización de la memoria dentro de la aplicación es excesiva hasta el punto de causar problemas con el agotamiento de la memoria. La recolección de elementos no deseados .Net lo limpiará automáticamente cuando intente asignar memoria adicional y el o/s se muera de hambre, o durante su próximo ciclo. Por lo general, no lo necesita a menos que su aplicación sea muy orientada al rendimiento. –

1

A menos que el "uso excesivo de memoria" sea un problema, lo dejaría como está y no me preocuparía por ello.

.NET es en la mayoría de los casos lo suficientemente inteligente como para evitar hacer una recolección de basura si tiene suficiente memoria disponible.

2

Si está generando muchos informes, podría considerar volver a utilizar un solo StringBuilder en lugar de asignar uno nuevo para cada informe.