Discussion :

[mjolymelot]

Bonsoir,


Je code en Pro*C.
J'ai un pb d'allocation mémoire.
J'utilise 3 tableaux de structure.
Ne connaissant pas la taille des tableaux en début de programme, je récupère l'info grâce une requête en base.
Ensuite, j'alloue la mémoire pour mes tableaux grâce à un malloc:

Code :

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

1
2
3
4
 
tableau1 = (struct Tableau*) malloc((t1)*(sizeof(struct Tableau))) ;
tableau2 = (struct Tableau2*) malloc((t2)*(sizeof(struct Tableau2))) ;
tableau3 = (struct Tableau*) malloc((t3)*(sizeof(struct Tableau))) ;

Actuellement, j'ai en BDD au maxi
500000 enreg pour le tableau1
350000 pour le tableau2
et le tableau3 est la synthèse des 2 donc maxi 850000.

L'exécution de mon programme plante toujours au même niveau d'exécution (en coredump).
Selon moi, ce n'est pas un pb de données dans la mesure où, si je restreints mon exécution autour des données utilisées au moment du plantage, le programme se termine correctement.

J'ai contrôlé toutes les fins de chaîne.
J'ai essayé de faire une déclaration de mes tableaux avec des tailles fixes mais là aussi plantage direct en début de programme.

Questions:
- Savez-vous s'il existe une taille maxi pour une définition en dur?
- Auriez-vous une idée pour corriger mon pb?

Merci beaucoup.
M JOLY MELOT

[Emmanuel Delahaye]

Je code en Pro*C.
J'ai un pb d'allocation mémoire.
J'utilise 3 tableaux de structure.
Ne connaissant pas la taille des tableaux en début de programme, je récupère l'info grâce une requête en base.
Ensuite, j'alloue la mémoire pour mes tableaux grâce à un malloc:

Code :

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

1
2
3
4
 
tableau1 = (struct Tableau*) malloc((t1)*(sizeof(struct Tableau))) ;
tableau2 = (struct Tableau2*) malloc((t2)*(sizeof(struct Tableau2))) ;
tableau3 = (struct Tableau*) malloc((t3)*(sizeof(struct Tableau))) ;

malloc() peut échouer. N'oublie pas de tester l'adresse avant de l'utiliser, et de libérer la mémoire après usage.

http://emmanuel-delahaye.developpez....tes.htm#malloc

J'ai contrôlé toutes les fins de chaîne.
J'ai essayé de faire une déclaration de mes tableaux avec des tailles fixes mais là aussi plantage direct en début de programme.

Questions:
- Savez-vous s'il existe une taille maxi pour une définition en dur?
- Auriez-vous une idée pour corriger mon pb?

La taille maximale garantie d'une variable statique est 32k en C90 et 64k en C99. Ca peut être plus selon l'implémentation.

Pour une variable automatique c'est beaucoup moins (quelques centaines de bytes). En fait ça dépend complément de l'implémentation et de l'exécution.

[koala01]

Salut,

Déjà, il faudrait pouvoir avoir une idée du contenu de tes quelques milliers d'enregistrements...

On ne demande pas de trahir un secret d'état, mais juste de pouvoir savoir s'il s'agit d'enregsitrement qui prennent quelques octets chacuns ou s'il s'agit de mémoires d'étudiants au grand complet (tu comprendra tout de suite que tu auras plus de chances de faire "abdiquer" l'application dans le second cas )

Ensuite, au vu du grand nombre d'enregistrements potentiel, il serait sans doute intéressant de pousser la réflection selon les termes suivants:

1. as-tu besoin de travailler sur les trois tables en même temps?
2. as-tu besoin de disposer de tous les enregistrement d'une table donnée en meme temp
3. le temps d'exécution est-il important, ou peux tu envisager de "laisser tourner l'application toute la nuit" pour son traitement
4. ne serait-il pas judicieux de diviser chaque table de manière cohérente en vue d'obtenir, par exemple 30 tables de 1000 enregistrements, et de sélectionner celle qui contiendra les enregistrements recherché/utilisés par ton application?
5. Ne pourrais tu envisager de modifier ta structure sous forme de liste (par exemple) pour n'allouer à chaque fois que la mémoire nécessaire au travail sur les enregistrements en cours?

Pour le point 5, je sais bien qu'une liste présente des désagréments vis à vis des tableaux, en rapidité d'acces, principalement, mais elle présenterais, à mon idée, l'énorme avantage de n'être pas obligé d'allouer 30.000 fois la taille d'un enregistrement d'un seul coup...

Pour la rapidité d'acces, un arbre binaire, correctement rempli, ne prendrait, par exemple que 16 itérations de recherche maximum pour trouver un enregistrement parmis 65.535 ... à méditer

[mehdi.berra]

A mon avis mjolimelot,tu devrais plutoto utiliser des fichiers car les chiffres que tu donnes pr tes strucutures sont vraiment enorme

l'utilisation de fichiers devrait resoudre ton probleme

[zooro]

Ses données sont dans une base de données. Il ne va pas les copier dans des fichiers avant de les transférer en mémoire ! Ca n'aurait aucun intérêt (enfin, sauf cas particulier, mais ce n'est pas le cas ici) !

[koala01]

Je le répète, selon moi, vu les nombres d'enregistrements cités, l'idéal est de partir sur une structure dynamique pour chaque enregistrements plutot que sur un seul tableau monolitique, fusse-t-il alloué dynamiquement...

Il est en effet plus facile de trouver la place en mémoire pour 50.000 "petits" blocs que pour un seul bloc devant contenir l'équivalant de ces 50.000 petits blocs...

Sans compter que cela contourne le problème de la taille maximale possible pour un "bloc"... La seule restriction restante à ce moment là, devenant la quantité de mémoire disponible pour l'application... Mais celle-là, on ne peut pas facilement la faire "sauter"

[zooro]

Oui, je suis de ton avis aussi.

[koala01]

Oui, je suis de ton avis aussi.

Moi aussi

Le seul problème étant alors le choix de la structure dynamique:

Une pile ou une file peut ne pas etre adaptée à son travail

Une liste, simplement ou doublement chainée provoquera un temps de latence interminable pour accéder au... 49.999 élément ou pour un tri global

un arbre binaire présentera des difficultés algorithmiques pour s'assurer de son remplissage optimal.

[Trap D]

On ne sait pas trop le traitement effectué sur les données, néanmoins j'essayerais ceci : plutôt que de copier les données en mémoire, je les laisserais sur le disque et je me contenterais d'un couple (ou un triplet) de nombres, (numero du fichier 1 ou 2, numero d'enregistrement dans le fichier ou offset & longueur) pour indexer les données.
Celà prendra beaucoup moins de place en mémoire, mais celà risque peut-être/surement de ralentir le traitement à cause du temps d'accès aux données, il faut tester.

[gijy]

La fonction farmalloc te permet d'allouer toute la memoire >à 64k (1 segment)
mais il faudra que tu compile en model far.
Malgré tous je pense que ce n'est pas la bonne sol et qu'il faut mieux travail sur tes fichiers.

[Emmanuel Delahaye]

La fonction farmalloc

keskidi ? Qui a parlé de x86 mode réel ?

Merci de ne pas raconter n'importe quoi...

[Patriarch24]

La question est : est-il nécessaire d'avoir toutes les données en mémoire en même temps ? En quoi consiste le traitement, si ce n'est pas un secret ?

Actuellement, j'ai en BDD au maxi
500000 enreg pour le tableau1
350000 pour le tableau2
et le tableau3 est la synthèse des 2 donc maxi 850000.

Il doit être possible d'éviter des copies en mémoire de ces enregistrements, même dans des fichiers... Mais il faut plus d'explications !