Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Visual Basic Allocation d'un gros bloc de mémoire

Allocation d'un gros bloc de mémoire

7 réponses
Avatar
Greg
Bonjour,

Je souhaite allouer un gros bloc de m=E9moire =E0 l'aide des=20
instructions suivantes :

Dim MonBloc() As Byte
ReDim MonBloc(1500000000) ' Soit 1.5Go de RAM

Au cours de l'ex=E9cution, je re=E7ois le message "Out of=20
Memory" alors que j'ai suffisamment de m=E9moire.

Merci d'avance,

Greg
Signaler un problème avec ce contenu

7 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Zoury
Salut Greg! :O)

J'serais curieux de connaître la raison pour laquelle tu as *besoin* de 1.5
Go de RAM... ? Tu veux il lire un gros fichier?

--
Cordialement
Yanick Lefebvre - MVP pour Visual Basic
http://faq.vb.free.fr/?rubrique=0 - http://www.mvps.org/vbnet/
http://www.mentalis.org/agnet/apiguide.shtml - http://www.mztools.com/
Avatar
ng
Et même ! On ne s'amuserait pas à charger un fichier de 1.5Go ds la RAM ! On
pourrait faire de "streaming" par exemple où le lire par morceau (avec pq
pas indexage ds l'header)

--
Nicolas G.
FAQ VB : http://faq.vb.free.fr
API Guide : http://www.allapi.net
Google Groups : http://groups.google.fr/
MZ-Tools : http://www.mztools.com/
http://apisvb.europe.webmatrixhosting.net/



Zoury a écrit :

Salut Greg! :O)

J'serais curieux de connaître la raison pour laquelle tu as *besoin*
de 1.5 Go de RAM... ? Tu veux il lire un gros fichier?


Avatar
jmn
Peut importe ce que vous voulez faire...

Sous VB les tableaux sont des SAFEARRAY, un type défini dans le contexte OLE
Automation. Ils sont caractérisés par la présence d'un en tête contenant les
informations de dimensions, de type, etc... et l'existence d'un groupe de
fonctions permettant la gestion du tableau.
En théorie, les dimensions d'un SAFEARRAY sont des 'unsigned long' (donc sur
4 octets) ce qui devrait permettre de définir des dimensions de l'ordre de 4
290 000 000 !

On peut en conclure que Monsieur le programmeur de l'interpréteur VB a
décider de mettre un test pour bloquer au delà de 200 000 000...

Mais, au fait, c'est pour faire quoi ?...
Avatar
Christophe
Bonjour,

Et oui pourquoi fair sachant qu'en plus une application a 2Go allouable ...

Essaye avec les APIs ci-dessous:
Private Declare Function GlobalAlloc& Lib "kernel32" (ByVal wFlags As Long,
ByVal dwBytes As Long)
Private Declare Function GlobalFree& Lib "kernel32" (ByVal Hmem As Long)
Private Declare Function GlobalLock& Lib "kernel32" (ByVal Hmem As Long)
Private Declare Function GlobalReAlloc& Lib "kernel32" (ByVal Hmem As Long,
ByVal dwBytes As Long, ByVal wFlags As Long)
Private Declare Function GlobalSize& Lib "kernel32" (ByVal Hmem As Long)
Private Declare Function GlobalUnlock& Lib "kernel32" (ByVal Hmem As Long)

Mais je reste tout de même méfiant sur l'allocation d'un si grand espace!

Christophe Vergon

"jmn" a écrit dans le message de news:

Peut importe ce que vous voulez faire...

Sous VB les tableaux sont des SAFEARRAY, un type défini dans le contexte


OLE
Automation. Ils sont caractérisés par la présence d'un en tête contenant


les
informations de dimensions, de type, etc... et l'existence d'un groupe de
fonctions permettant la gestion du tableau.
En théorie, les dimensions d'un SAFEARRAY sont des 'unsigned long' (donc


sur
4 octets) ce qui devrait permettre de définir des dimensions de l'ordre de


4
290 000 000 !

On peut en conclure que Monsieur le programmeur de l'interpréteur VB a
décider de mettre un test pour bloquer au delà de 200 000 000...

Mais, au fait, c'est pour faire quoi ?...






Avatar
Greg
Bonjour,

Merci pour vos réponse
En fait, l'exemple que je vous ai donné était pour simplifier les choses et être certain que cela se produise sur vos machines

En fait, c'est pour traiter des données scientifiques en 3 dimensions et selon les machines (et indépendamment de la RAM dont elles disposent) je reçois le message pour des blocs faisant 800 x 800 x 512 soit seulement environ 330 Mo de RAM

Ce que j'ai le plus de mal à comprendre c'est qu'une même machine accepte parfois d'allouer un bloc de grande taille mais pas toujours

De plus j'ai remarqué qu'en allouant successivement des blocs de plus en plus gros, on arrive parfois à repousser les limites (mais pas toujours)

Cela se produit également avec du code écrit en C++, ce qui me fait penser que cela vient peut-être de Windows et non de VB ou VC++

Si quelqu'un à d'autres idées..
Ou si quelqu'un a une idée d'un newsgroup plus approprié pour cette question..

Merc

Gre




----- Christophe a écrit : ----

Bonjour

Et oui pourquoi fair sachant qu'en plus une application a 2Go allouable ..

Essaye avec les APIs ci-dessous
Private Declare Function GlobalAlloc& Lib "kernel32" (ByVal wFlags As Long
ByVal dwBytes As Long
Private Declare Function GlobalFree& Lib "kernel32" (ByVal Hmem As Long
Private Declare Function GlobalLock& Lib "kernel32" (ByVal Hmem As Long
Private Declare Function GlobalReAlloc& Lib "kernel32" (ByVal Hmem As Long
ByVal dwBytes As Long, ByVal wFlags As Long
Private Declare Function GlobalSize& Lib "kernel32" (ByVal Hmem As Long
Private Declare Function GlobalUnlock& Lib "kernel32" (ByVal Hmem As Long

Mais je reste tout de même méfiant sur l'allocation d'un si grand espace

Christophe Vergo

"jmn" a écrit dans le message de news

> Peut importe ce que vous voulez faire..
>> Sous VB les tableaux sont des SAFEARRAY, un type défini dans le context
OL
> Automation. Ils sont caractérisés par la présence d'un en tête contenan
le
> informations de dimensions, de type, etc... et l'existence d'un groupe d
> fonctions permettant la gestion du tableau
> En théorie, les dimensions d'un SAFEARRAY sont des 'unsigned long' (don
su
> 4 octets) ce qui devrait permettre de définir des dimensions de l'ordre d

> 290 000 000
>> On peut en conclure que Monsieur le programmeur de l'interpréteur VB
> décider de mettre un test pour bloquer au delà de 200 000 000..
>> Mais, au fait, c'est pour faire quoi ?..
>>>>
Avatar
Christophe
Essayes les APIs dans un module public avec des blocs types
Private Const GMEM_MOVEABLE& = &H2
J'utilise ceci avec des images de grande taille 12Mo à 15 Mo par images et
sous XP j'arrive à en charger plus de 15 (j'ai pas testé plus) sans que cela
pose de pb.

Le fait d'utiliser les API te dispense de faire intervenir une structure
SAFEARRAY.
tu peux aussi utiliser
IsbadWritePtr qui te permet de savoir si un bloc mémoire est valide et si on
peut ecrire dessus.

Christophe Vergon


"Greg" a écrit dans le message de
news:
Bonjour,

Merci pour vos réponse.
En fait, l'exemple que je vous ai donné était pour simplifier les choses


et être certain que cela se produise sur vos machines.

En fait, c'est pour traiter des données scientifiques en 3 dimensions et


selon les machines (et indépendamment de la RAM dont elles disposent) je
reçois le message pour des blocs faisant 800 x 800 x 512 soit seulement
environ 330 Mo de RAM.

Ce que j'ai le plus de mal à comprendre c'est qu'une même machine accepte


parfois d'allouer un bloc de grande taille mais pas toujours.

De plus j'ai remarqué qu'en allouant successivement des blocs de plus en


plus gros, on arrive parfois à repousser les limites (mais pas toujours).

Cela se produit également avec du code écrit en C++, ce qui me fait penser


que cela vient peut-être de Windows et non de VB ou VC++.

Si quelqu'un à d'autres idées...
Ou si quelqu'un a une idée d'un newsgroup plus approprié pour cette


question...

Merci

Greg






----- Christophe a écrit : -----

Bonjour,

Et oui pourquoi fair sachant qu'en plus une application a 2Go


allouable ...

Essaye avec les APIs ci-dessous:
Private Declare Function GlobalAlloc& Lib "kernel32" (ByVal wFlags As


Long,
ByVal dwBytes As Long)
Private Declare Function GlobalFree& Lib "kernel32" (ByVal Hmem As


Long)
Private Declare Function GlobalLock& Lib "kernel32" (ByVal Hmem As


Long)
Private Declare Function GlobalReAlloc& Lib "kernel32" (ByVal Hmem As


Long,
ByVal dwBytes As Long, ByVal wFlags As Long)
Private Declare Function GlobalSize& Lib "kernel32" (ByVal Hmem As


Long)
Private Declare Function GlobalUnlock& Lib "kernel32" (ByVal Hmem As


Long)

Mais je reste tout de même méfiant sur l'allocation d'un si grand


espace!

Christophe Vergon

"jmn" a écrit dans le message de news:

> Peut importe ce que vous voulez faire...
>> Sous VB les tableaux sont des SAFEARRAY, un type défini dans le


contexte
OLE
> Automation. Ils sont caractérisés par la présence d'un en tête


contenant
les
> informations de dimensions, de type, etc... et l'existence d'un


groupe de
> fonctions permettant la gestion du tableau.
> En théorie, les dimensions d'un SAFEARRAY sont des 'unsigned long'


(donc
sur
> 4 octets) ce qui devrait permettre de définir des dimensions de


l'ordre de
4
> 290 000 000 !
>> On peut en conclure que Monsieur le programmeur de l'interpréteur


VB a
> décider de mettre un test pour bloquer au delà de 200 000 000...
>> Mais, au fait, c'est pour faire quoi ?...
>>>>


Avatar
Patrice Henrio
Je pense que cela a à voir avec ce que l'on appelle dans d'autres langages
le "garbage collector", le ramasse miettes. je crois que pour un tableau la
mémoire doit être contiguë. Donc pour cette allocation, on ramasse les
miettes éparses de mémoires, un peu comme defrag, puis on déplace les
morceaux pour obtenir un espace suffisamment grand. cela prend du temps et
on est même pas sûr que cela va marcher.
"Greg" a écrit dans le message de
news:
Bonjour,

Merci pour vos réponse.
En fait, l'exemple que je vous ai donné était pour simplifier les choses


et être certain que cela se produise sur vos machines.

En fait, c'est pour traiter des données scientifiques en 3 dimensions et


selon les machines (et indépendamment de la RAM dont elles disposent) je
reçois le message pour des blocs faisant 800 x 800 x 512 soit seulement
environ 330 Mo de RAM.

Ce que j'ai le plus de mal à comprendre c'est qu'une même machine accepte


parfois d'allouer un bloc de grande taille mais pas toujours.

De plus j'ai remarqué qu'en allouant successivement des blocs de plus en


plus gros, on arrive parfois à repousser les limites (mais pas toujours).

Cela se produit également avec du code écrit en C++, ce qui me fait penser


que cela vient peut-être de Windows et non de VB ou VC++.

Si quelqu'un à d'autres idées...
Ou si quelqu'un a une idée d'un newsgroup plus approprié pour cette


question...

Merci

Greg






----- Christophe a écrit : -----

Bonjour,

Et oui pourquoi fair sachant qu'en plus une application a 2Go


allouable ...

Essaye avec les APIs ci-dessous:
Private Declare Function GlobalAlloc& Lib "kernel32" (ByVal wFlags As


Long,
ByVal dwBytes As Long)
Private Declare Function GlobalFree& Lib "kernel32" (ByVal Hmem As


Long)
Private Declare Function GlobalLock& Lib "kernel32" (ByVal Hmem As


Long)
Private Declare Function GlobalReAlloc& Lib "kernel32" (ByVal Hmem As


Long,
ByVal dwBytes As Long, ByVal wFlags As Long)
Private Declare Function GlobalSize& Lib "kernel32" (ByVal Hmem As


Long)
Private Declare Function GlobalUnlock& Lib "kernel32" (ByVal Hmem As


Long)

Mais je reste tout de même méfiant sur l'allocation d'un si grand


espace!

Christophe Vergon

"jmn" a écrit dans le message de news:

> Peut importe ce que vous voulez faire...
>> Sous VB les tableaux sont des SAFEARRAY, un type défini dans le


contexte
OLE
> Automation. Ils sont caractérisés par la présence d'un en tête


contenant
les
> informations de dimensions, de type, etc... et l'existence d'un


groupe de
> fonctions permettant la gestion du tableau.
> En théorie, les dimensions d'un SAFEARRAY sont des 'unsigned long'


(donc
sur
> 4 octets) ce qui devrait permettre de définir des dimensions de


l'ordre de
4
> 290 000 000 !
>> On peut en conclure que Monsieur le programmeur de l'interpréteur


VB a
> décider de mettre un test pour bloquer au delà de 200 000 000...
>> Mais, au fait, c'est pour faire quoi ?...
>>>>