Discussion :

[sone47]

Bonjour,

J'utilise un conteneur dans un reader de données que je remplis au fil du temps.
Le problème est que la taille finale de la totalité des objets lus fait que l'application consomme beaucoup trop de mémoire.

Étant donnée que mes conteneurs ne sont que des attributs de ma classe de stockage, il me semble que la mémoire utilisée soit la stack.

Que puis je envisager pour me libérer de ces contraintes de taille ?

1- Allouer dynamiquement mes conteneurs pour utiliser une autre zone mémoire ?
2- Redéfinir un conteneur qui selon sa taille maximale autorisée (configuré par l'utilisateur) écrira tout l'excès mémoire dans des binaires sur disque.

Merci d'avance !

[LandReagan]

Bonjour,

Qu'est-ce que tu appelles beaucoup trop de mémoire, et sur quel matériel?

Étant donnée que mes conteneurs ne sont que des attributs de ma classe de stockage, il me semble que la mémoire utilisée soit la stack.

Cela dépend de la nature de tes attributs, non ? Si ce sont des pointeurs, par exemple, il y a de grandes chances qu'ils pointent sur le tas.

Un peu de code à se mettre sous la dent ?

[sone47]

Bonjour,

Oui pardon je me suis mal exprimé, et en plus je me suis trompé.
ma classe de stockage étant créée dynamiquement, je suis déja sur la pile.

Le principe est simple je n'ai listé que la partie concernée:

Code :

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

1
2
3
4
5
6
7
8
 
class stockageParams
{
vector<myValues> mVectValues;
bool setVectorValues(vector<myValues>& arVector);
bool addValues(myValues & aVal);
myValues getValues(unsigned int aId);
}

En gros ma classe de stockage est créée dynamiquement lorsque mon reader parse mon fichier d'entrée.
Le reader fournit un gros vecteur de "myValues".

Le problème c'est que cette classe de stockage est utilisée pour chaque paramètre.
Avec plusieurs milliers de paramètre de plusieurs milliers de "myValues", l'appli finit dans certains cas en saturation mémoire et crash.

L'idée est donc de spécifier une taille max mémoire pour chaque "stockageParams" et ne garder que la plage autorisée.
(l'autre étant par exemple ecrite dans des binaires sur disque).
La méthode getValues renverrai donc directement les valeurs stockées dans la l'instance "stockageParams" si l'id correspond à une plage mémoire sauvée dans la pile, sinon elle irait lire dans des binaires pour le reconstruire à la volée.

Merci !

[ternel]

Ta classe me semble très bizarre, à cause de sa gestion des const.

pourquoi setVectorValues (qui pourrait s'appeler setValues ou même operator=) ne prend pas son argument en référence constante?
pourquoi addValues ne prend pas une référence constante?
pourquoi getValues n'est pas const et ne renvoie pas une référence constante?

En dehors de cela, il s'agit simplement d'encapsuler un vecteur et ca ne doit pas être plus cher que le vecteur lui-même.

[sone47]

Merci pour le retour,

Oui réécriture rapide, les set et add sont constants.
Pour le get c'est vrai qu'on peut retourner une reférence constante et laisser le choix à l'utilisateur de la recopier s'il veut la modifier, c'est plus cohérent.
Quand tu dis pas bien plus cher que le vecteur lui même tu parles de quoi ?

[ternel]

Question consommation, le vecteur est au même endroit que l'objet le contenant, il n'y a pas de surcout spécial.

Par contre, si tu essaie de charger énormément de donnée, essaie de réécrire le reader facon itérateur.

operator++ parse une ligne
operator* renvoie (une référence constante vers) la valeur lue lors de l'analyse.

à la construction, ou durant ++, tu lis une ligne, et si tu ne peux pas, tu prétends être end.
end n'étant qu'une valeur arbitraire.

Tu peux aussi utiliser une interface du genre:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class Reader<T> {
private:
    T last;
    bool valid
    <le stream> stream
public:
    Reader(...) : stream(...), valid(stream >> last) {}
 
    T const& value() const {return last;}
 
    bool next() {
        return valid ? stream>>last : false;//false ou valid, c'est pareil
    }
};

stream étant probablement un ifstream ou une référence non constante sur un ifstream. Les deux choix sont négociables.

Comme le code est finalement simple, tu n'as même pas vraiment besoin du reader, mais d'un istream& operator>>(istream&, myValues &).

Tout cela demande cependant que le format du fichier soit compatible avec la lecture séquentielle.
C'est à dire, que les entrées ne soient pas entrelacées.