Taille maximale de la mise en mémoire d'un exécutable

**newik01** · 19/05/2009, 10h55

J'aimerai savoir s'il y a une limitation de taille à la mise en mémoire d'un logiciel.
Je travail sur des image et ai besoin de créer de grands Bitmap. Or dés qu'en RAM le logiciel dépasse environ 1,3 Go j'obtiens comme message : "Le projet a déclenché la classe d'exception EOutOfRessource avec le message 'Ressource système insuffisantes'."
J'ai 4 Go de Ram, elle n'est donc pas saturée.

Est-ce une réelle limitation de taille? Et d'où vient-elle?
Y a-t-il un moyen d'augmenter l'espace utilisable?

Merci pour votre aide.

**Gilbert Geyer** · 19/05/2009, 12h06

Bonjour,

Ben, si t'as 4 Go de Ram et que "Le projet déclenche la classe d'exception EOutOfRessource avec le message 'Ressource système insuffisantes'." ça veut dire que la Ram est saturée par autre chose.
Cette autre chose peut être la mem-vive squattée par d'autres applications mais avec 4 Go il y a de la marge ou peut-être tout bêtement que ton logiciel qui n'occupe qu'environ 1,3 Go au moment de son lancement génère des fuites de mémoire qui finissent par saturer ta Ram.
Ou bien qu'à force de "créer de grands Bitmap" ce sont eux qui saturent la Ram.

A+

**newik01** · 19/05/2009, 13h14

Merci pour ta réponse.
Avant je n'avais que 2 Go de mémoire et j'avais le même problème.
J'ai aussi testé sur d'autres ordinateur et même résultat.
J'ai créé une application avec uniquement un bouton qui cré mon bitmap 22343*22000 donc un code de 10 lignes, je ne pense donc pas qu'il puisse y avoir de fuite de mémoire. Je lance le gestionnaire de tâches windows et quand j'appuie sur le bouton, je vois que la charge dédiée sur mon PC passe de 935 Mo à 2330 Mo et mon projet de 3300 Ko à 1 447 740 Ko
Ma RAm n'est donc pas saturée.
Par contre si je cré un Bitmap de 22343*22000, j'obtiens une erreur.

**Gilbert Geyer** · 19/05/2009, 13h33

Re-salut,

Ben si ton code ne fait que 10 lignes, publies le donc ici. Peut-être que quelqu'un y trouvera la cause du problème ... en tous cas on y verra plus clair ... et même si le code n'était pas en cause ça permettra au moins d'en avoir la certitude car jusqu'à présent on discute un peu dans le vide.

A+.

**Andnotor** · 19/05/2009, 14h00

Juste pour info, un bitmap 32 bits de 22343*22000 représente déjà 1.97 GB et 1.47 GB en 24 bits

Peut-être as-tu besoin de grandes images, mais as-tu besoin d'une telle profondeur des couleurs ?

**ShaiLeTroll** · 19/05/2009, 14h28

Voir ce sujet sur Phidels "Memoire D7", ou l'on a constaté que l'on ne pouvait allouer que 2048 Mo au maximum pour tous le programme (Mémoire des Handles Window + mémoire Programme dont RAM et Virtuelle) ce qui amène un chiffre de 1973Mo (au mieux), chiffre qui tombe au fur et à mesure que la machine reste allumée ...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
 
program MaxAlloc2Go;
 
{$R *.res}
 
uses
  Windows,
  SysUtils;
 
type
  TByteMatrix1024By1024 = array [0..1023, 0..1023] of Byte;
  TByteMatrix1024By1024Array = array[0..2047] of ^TByteMatrix1024By1024;
 
var
  Tableau: TByteMatrix1024By1024Array;
  I, K: Integer;
 
begin
  for I := 0 to 2047 do
  begin
    try
      Tableau[I] := Pointer(GlobalAlloc(GMEM_FIXED, 1024*1024));
      if Tableau[I] = nil then
        Abort;
      K := I;
    except
      on E: Exception do
      begin
        OutputDebugString(PChar(Format('Last Alloc %d', [I])));
        Break;
      end;
    end;
  end;
 
  MessageBox(0, PChar(Format('Last Alloc %d', [K])), nil, MB_OK+MB_ICONEXCLAMATION);
 
  if K = 2047 then
    OutputDebugString('Alloc 2Go');
 
  for I := K downto 0 do
    try
      // FreeMem(Tableau[I]);
      if GlobalFree(Cardinal(Tableau[I])) <> 0 then
        Abort;
    except
      on E: Exception do
        OutputDebugString(PChar(Format('Free %d : %s', [K, E.Message])));
    end;
 
 
end.

**newik01** · 19/05/2009, 15h21

Envoyé par Gilbert Geyer

Re-salut,

Ben si ton code ne fait que 10 lignes, publies le donc ici. Peut-être que quelqu'un y trouvera la cause du problème ... en tous cas on y verra plus clair ... et même si le code n'était pas en cause ça permettra au moins d'en avoir la certitude car jusqu'à présent on discute un peu dans le vide.

A+.

Voici le code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
procedure TForm1.Button1Click(Sender: TObject);
var BMP : TBitmap;
begin
  BMP := TBitmap.Create;
  BMP.PixelFormat := pf24bit;
  BMP.Height := 22343;
  BMP.Width := 22000;
end;

Juste pour info, un bitmap 32 bits de 22343*22000 représente déjà 1.97 GB et 1.47 GB en 24 bits

Peut-être as-tu besoin de grandes images, mais as-tu besoin d'une telle profondeur des couleurs ?

Oui, j'ai besoin de cette profondeur.

Envoyé par ShaiLeTroll

Voir ce sujet sur Phidels "Memoire D7", ou l'on a constaté que l'on ne pouvait allouer que 2048 Mo au maximum pour tous le programme (Mémoire des Handles Window + mémoire Programme dont RAM et Virtuelle) ce qui amène un chiffre de 1973Mo (au mieux), chiffre qui tombe au fur et à mesure que la machine reste allumée ...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
 
program MaxAlloc2Go;
 
{$R *.res}
 
uses
  Windows,
  SysUtils;
 
type
  TByteMatrix1024By1024 = array [0..1023, 0..1023] of Byte;
  TByteMatrix1024By1024Array = array[0..2047] of ^TByteMatrix1024By1024;
 
var
  Tableau: TByteMatrix1024By1024Array;
  I, K: Integer;
 
begin
  for I := 0 to 2047 do
  begin
    try
      Tableau[I] := Pointer(GlobalAlloc(GMEM_FIXED, 1024*1024));
      if Tableau[I] = nil then
        Abort;
      K := I;
    except
      on E: Exception do
      begin
        OutputDebugString(PChar(Format('Last Alloc %d', [I])));
        Break;
      end;
    end;
  end;
 
  MessageBox(0, PChar(Format('Last Alloc %d', [K])), nil, MB_OK+MB_ICONEXCLAMATION);
 
  if K = 2047 then
    OutputDebugString('Alloc 2Go');
 
  for I := K downto 0 do
    try
      // FreeMem(Tableau[I]);
      if GlobalFree(Cardinal(Tableau[I])) <> 0 then
        Abort;
    except
      on E: Exception do
        OutputDebugString(PChar(Format('Free %d : %s', [K, E.Message])));
    end;
 
 
end.

Merci pour ce lien. J'ai bien peur de ne pas avoir de solution. J'ai essayé avec FastMM4 mais pas d'amélioration.

**ShaiLeTroll** · 19/05/2009, 18h23

FastMM4 n'améliore les choses que sous un Win64 pour le taille maximale que l'on peut allouer par process avec Delphi 7

Sinon, je pense qu'il est temps pour toi de te plonger dans ce qu'un un fichier bitmap, et de la manipuler avec les API Windows pour ce qui est de la partie "entête" (le DIB, je crois), mais tous le reste, il faudrait le manipuler autrement, peut-être directement dans le fichier (ou par un fichier intermédiaire) ... PhotoShop par exemple ne charge pas tout le fichier en mémoire, il utilise un cache sur le disque (rien est pire que le SWAP, mieux vaut manipuler un gros tableau d'un 1Go sur le disque soit même directement que de vouloir utiliser que de la mémoire vive et laisser faire windows qui swappe n'importe quand pour n'importe quoi, cela se voit sur les ré-allocation de tableau, où après une certaine taille, cela devient plus lent que d'écrire dans un fichier, ceci est valable pour le gestionnaire mémoire de D7, FastMM améliore le choses à ce sujet, il me semble ...)

**newik01** · 20/05/2009, 16h19

Envoyé par ShaiLeTroll

FastMM4 n'améliore les choses que sous un Win64 pour le taille maximale que l'on peut allouer par process avec Delphi 7

Sinon, je pense qu'il est temps pour toi de te plonger dans ce qu'un un fichier bitmap, et de la manipuler avec les API Windows pour ce qui est de la partie "entête" (le DIB, je crois), mais tous le reste, il faudrait le manipuler autrement, peut-être directement dans le fichier (ou par un fichier intermédiaire) ... PhotoShop par exemple ne charge pas tout le fichier en mémoire, il utilise un cache sur le disque (rien est pire que le SWAP, mieux vaut manipuler un gros tableau d'un 1Go sur le disque soit même directement que de vouloir utiliser que de la mémoire vive et laisser faire windows qui swappe n'importe quand pour n'importe quoi, cela se voit sur les ré-allocation de tableau, où après une certaine taille, cela devient plus lent que d'écrire dans un fichier, ceci est valable pour le gestionnaire mémoire de D7, FastMM améliore le choses à ce sujet, il me semble ...)

Merci beaucoup. Je vais donc changer ma manière de gérer mes images.

**Franck SORIANO** · 21/05/2009, 16h11

Il faut savoir que du fait du mode de gestion de la mémoire des Windows 32 bits, chaque processus à une limitation d'adressage à 2 Go.

Peu importe que la machine possède 4 Go, aucune application ne peut s'allouer plus de 2 Go de mémoire.
Par contre, plusieurs applications peuvent utiliser 2 Go chacune...(et la on profite des n Go que Windows voudra bien détecter).

Il est possible de relever cette limitation à 3 Go, en ajoutant le switch /3GB au démarrage de windows (dans le fichier boot.ini).

Cependant, je ne pense pas que ce soit un problème de mémoire vive. Tu aurrais dû avoir une erreur EOutOfMemory et non pas EOutOfRessource.
Je pense plutôt que c'est le GDI qui rend l'âme pour gérer une image de cette taille.

Ca ne change pas grand chose. Le résultat est le même. Il faut effectivement que tu gères tes images différemments.