Announcement

**Hagen Reddmann** · 11.03.2002, 23:29

<pre>

<code>type
PPtr = ^TPtr;
TPtr = packed record
Next: PPtr;
end;
 
procedure CleanMemory;
 
procedure Release(P: PPtr);
begin
if P <> nil then
begin
Release(P.Next);
VirtualFree(P, 0, MEM_RELEASE);
end;
end;
 
var
R,P: PPtr;
S: Cardinal;
L: Integer;
K: PChar;
M: TMemoryStatus;
begin
R := nil;
S := 1024 * 64;
try
repeat
P := VirtualAlloc(nil, S, MEM_COMMIT, PAGE_READWRITE or PAGE_NOCACHE);
if P <> nil then
begin
K := PChar(P);
L := 0;
while L < S do
begin
K^ := #55;
Inc(K, 1024);
Inc(L, 1024);
end;
P.Next := R;
R := P;
end else S := S shr 1;
M.dwLength := SizeOf(M);
GlobalMemoryStatus(M);
until (S = 0) or (M.dwMemoryLoad >= 99);
finally
Release(R);
end;
end;

</code></pre>
&#10

**Hagen Reddmann** · 11.03.2002, 23:34

Es besteht ein gewaltiger Unterschied zwischen mit GetMem() oder VirtualAlloc() angefordertem Speicher und tats�chlich genutzten Speicher. Das OS ist schon so clever zu erkennen das du den mit getMem() angeforderten Speicher �berhaupt nicht nutzt. Erst wenn wirklich auch dieser Speicher gelesen oder geschrieben wird, wird der Speicher im Hauptspeicher fixiert. 
Obiger Code verdeutlicht das sehr gut, einfach mal die Loop in der K^ := #55 gesetzt wird auskommentieren. 

Gru� Hage

**Hagen Reddmann** · 11.03.2002, 23:40

@Gesine, na alte K�mpferin

Ich habe es mittlerweile aufgegeben den Jungen was von effizienter und zielorientierter Programierung zu verklickern. 
Sieh's einfach so: Jeder mu� mal seine Erfahrungen machen und lernt nat�rlich so dazu. �brigens auch Du oder Ich haben wahrscheinlich mal so angefangen

@Juliman, sieh's nicht so eng. Im grunde treffen hier zwei Welten aufeinander, JEDE hat seine Berechtigung. 
Grunds�tzlich ist aber das was du versuchst reine Zeitverschwendung und mit einem "weinenden" Auge bedauere ich nicht soviel Zeit wie du zu haben.

Gru� hage

**Gesine Kuhlmann** · 11.03.2002, 23:48

Hi Juliman,

Worauf ich hinaus wollte:

1)
W�hle immer das richtige Werkzeug, um ein Problem effektiv zu l�sen. Im Zweifel bedeutet dies sogar einen, oft auch viel einfacheren und kosteng�nstigeren, BS-Wechsel.

2)
Der in EDV-Umgebung gern zitierte und dummerhaftige Spruch 'geht nicht gibt's nicht' f�hrt nie zum Ziel, sondern verbrennt nur ( meistens deine ) wichtige Lebenszeit.

3)
Kaum ein Problem l�sst sich heute, egal auf welcher aktuellen Hardware und welchem BS, nicht l�sen sofern der passende Algorithmus gew�hlt wurde.

4) Wie kann man heute Arbeitsspeicherprobleme bekommen, wenn man 1GB fast auf'm Grabbeltisch bekommt ??

Gru�
Gesine

P.S.
Soviel zum Wort zum Montag ;-

**Gesine Kuhlmann** · 12.03.2002, 00:14

Hi Hagen,

Irgendwie bin ich heute extrem lahm. Schon wieder drei Beitr�ge w�hrend des Schreibens verpennt.

Oh Gott, ich glaub' ich werd' alt. ;-)

Gru�
Gesin

**Gast_1** · 12.03.2002, 14:43

Hi Hagen und Gesine,

herzlichen Dank f�r eure klasse Hilfe. Hagens Quellcode funktioniert einwandfrei und ist auch ziemlich einfach zu verstehen. 
Klar kann man einfach mehr Ram kaufen, blo� hilft mir das auch nicht weiter, wenn einfach viele M�ll-DLLs geladen sind und den Arbeitsspeicher verstopfen. 
Nat�rlich habe ich auch nicht viel Zeit, wahrscheinlich aber noch mehr als du, Hagen... Trotzdem wollte ich dieses Problem l�sen :-). 
Nochmals herzlichen Dank !

**Hagen Reddmann** · 12.03.2002, 16:30

wenn einfach viele M�ll-DLLs geladen sind und den Arbeitsspeicher verstopfen. 

und genau das ist kein Argument ! Wenn viele DLL's den RAM verstopfen und ein Prozess mehr Speicher anfordert als vorhanden ist wird automatisch Platz geschafft indem diese wenig genutzten Module in die Swapdatei ausgelagert werden. Windows lagert nun genau so viel aus wie n�tig ist um dem Prozess seinen Speicher geben zu k�nnen. Es kommt sogar noch besser. Windows erkennt n�mlich sehr genau wann eine Anwendung/Prozess in den Hintergrund verlagert wird und lagert pr�ventiv in der Leerlaufzeit dessen Module aus. Damit schafft windows je nach Situation immer gen�gen verf�gbaren Speicher OHNE das es viel Zeit kostet. bzw ohne das es wertvolle Zeit kostet. 
Fazit: egal welche Argumente Du anf�hrst in JEDEM Szenario wird Windows den optimaleren Weg gehen. Das liegt einfach daran, da� sich viel hellere K�pfe als wir es je sein werden dar�ber schon jahrelang Gedanken gemacht haben. 
�brigens, aufbauend auf diesen Gedanken setzen z.B. Gesine und ich voraus das sich darum jedes vern�nftige OS und deren Entwickler k�mmern und somit das Rad nicht zweimal erfunden werden mu�. 
Ein gutes Swapping und Virtuelles Speichermanagement geh�rt zu jedem guten OS !

Gru� Hage

**Andreas Kosch** · 13.03.2002, 08:51

Hallo,

wenn die Anwendung unter Windows NT 4/2000/XP l�uft, r�umt die Win32-API-Funktion SetProcessWorkingsetsize auf Wunsch so auf, dass die eigene Anwendung die maximal verf�gbaren Speicher erh�lt

Announcement

Ram freigeben ?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment