muchas varibles locales, como consumir menos memoria

[JerS]

amigos en un procedimiento declaro muchas varibles locales, cuando digo muchas me refiero a 120 varables locales , este procedimiento se llama varias veces por minuto, que recomendación me dan para disminuir el consumo de memoria. y la mayoria de las variables son String. el comsumo de memoria es menor si limito la declaracion del string Ejm:

Código Delphi [-]
prueba : string[4];
/// consume menos memoria que

prueba : string;

[ecfisa]

Hola

Sin entrar a polemizar sobre la conveniencia del uso de variables globales ya que no conozco el caso, yo usaría long strings (string) que son punteros y pueden incrementarse/decrementarse dinámicamente acorde a los valores asignados.
Para ellas, Delphi utiliza un contador de apuntadores que referencian al valor almacenado (reference counter) y cuando este llega a 0 la memoria es liberada. Al ser apuntadores, copiar una variable tipo string es más veloz que copiar una tipo ShortString.

Y por último al ser un puntero, la declaración de una variable string ocupa 4 bytes y la de una string[4] ocupa 5 (en la posición cero almacena la longitud de la cadena), es fácil de comprobar:

Código Delphi [-]
var
  s4: string[4];
  st: string;

implementation

procedure TForm1.Button1Click(Sender: TObject);
begin
  ShowMessage(Format('s4: %d bytes,  st: %d bytes',[SizeOf(s4),SizeOf(st)]));
end;

Aunque a decir verdad, declarando todas las variables como string[4] nunca superarás un uso de memoria de 5 * 120 = 600 bytes (los uses o no).
En cambio declarando todas como string, si bién incialmente se consumen 4 * 120 = 580 bytes, el uso de memoria será mayor si les asignas más de 5 caracteres.

Un saludo.

[Neftali [Germán.Estévez]]

Si se trata de buscar optimizaciones, habría que ver el procedimiento con detalle, para tener información completa.

Por un lado se me hace difícil pensar en 120 variables, básicamente no me imagino para qué pueden hacer falta y si son todas necesarias. No se si habría forma de reutilizarlas o de diseñar eso de otra forma.
Por otro lado si son variables locales, al salir del procedimiento esa memoria se libera, por lo que no debería representar un conveniente llamarlo las veces que sean necesarias. Cada llamada no implica más gasto si todo se libera correctamente.

[[Al González]]

Empezado por Neftali

Por otro lado si son variables locales, al salir del procedimiento esa memoria se libera, por lo que no debería representar un conveniente llamarlo las veces que sean necesarias. Cada llamada no implica más gasto si todo se libera correctamente.

Hola Germán. Respecto al consumo de memoria, puede que no sea demasiado problema como bien dices.

Pero cabe mencionar que con 120 variables el consumo de CPU puede resultar importante, dependiendo en buena medida de qué tantas de esas variables usen contadores de referencias (debido a las necesarias inicializaciones y finalizaciones), y de la frecuencia con que la rutina es llamada: varias veces por minuto, según comenta JerS.

JerS, como ya dijo Neftalí, habría que ver ese procedimiento con detalle. ¿Sería posible que colocaras aquí una copia del mismo, o al menos algo que se le asemeje en caso de ser muy confidencial?

Saludos.

Al González.

[JerS]

Muchas gracias por sus aportes, por lo que he podido entender no hay mucha diferencia entonces entre declarar la variable como String o String[4] y al declarar las variables como locales al terminar el proceso son liberadas de memoria sin problema. entonces este no es el problema de mi procedimiento, lo que sucede es que es un procedimiento muy extenso de mas de 2000 lineas y en cierto punto sobre todo al hacer ZQuery1.Open me da problemas de Access Violation o Invalit pointer operation o muchas veces en algo tan sencillo como edit1.clear; por eso estoy descartando que puede ser :S

[Neftali [Germán.Estévez]]

Empezado por JerS

...lo que sucede es que es un procedimiento muy extenso de mas de 2000 lineas y en cierto punto sobre todo al hacer ZQuery1.Open me da problemas de Access Violation o Invalit pointer operation o muchas veces en algo tan sencillo como edit1.clear; por eso estoy descartando que puede ser :S

Te recomiendo dividir el procedimiento en secciones más pequeñas, para poder detectar los errores de forma más fácil.
Utiliza Try...except para capturar posibles excepciones.
Revisa elementos que creas y destruyes en el procedimiento, puesto que los Access Violation suelen ser debidos a accesos incorretos a memoria (por ejemplo cosas que todavía no se han creado al accederlas o que se han destruído antes de tiempo).