PureBasic

Salut à toi ! j'ai aussi une réponse simple , n'utilise pas Allocatememory() , cette fonction n'est pas optimisé , elle bouffe de la mémoire vive , ne déclare pas non plus de variables...

Non , plus sérieusement , explique nous tes besoins , & du code , y a que ca de vrai

Salut Neosis,

Peut-être que tu peux remplacer ta liste chaînée par une liste perso avec AllocateMemory et compagnie. Mais dans ce cas, tu es dans la mouise pour tout convertir...

Je n'utilise jamais les linkedlists à cause de ça. J'ai donc des codes assez illisibles mais qui peuvent être assez gourmand au niveau mémoire.

Le plus dur dans ce cas, c'est de créer les fonctions d'insertion et de suppression. Pour ma part, j'ai 2 fonctions assembleur assez courtes qui sont équivalentes à MoveMemory().

Maintenant, il y a peut-être mieux que cette méthode, mais je ne les connais pas...

Je ne te comprends toujours pas.... que tu utilises une liste un tabelau , des allocates , pour stocker des données , la mémoire consommé reste la même , après , c'est la vitesse d'execution , mais ce n'est pas le sujet. par contre si tu veut stocker un caractère ASCII un quad te servirais à rien... c'est tout ce qui faut savoir.

Si ton nombre à stocker varie entre 0 et 255 , un .c fait l'affaire et te bouffe 1 octets...
pas besoin d'un quad dans ce cas.

@++

Cpl.Bator a écrit :Je ne te comprends toujours pas.... que tu utilises une liste un tabelau , des allocates , pour stocker des données , la mémoire consommé reste la même , après , c'est la vitesse d'execution , mais ce n'est pas le sujet. par contre si tu veut stocker un caractère ASCII un quad te servirais à rien... c'est tout ce qui faut savoir.

Si ton nombre à stocker varie entre 0 et 255 , un .c fait l'affaire et te bouffe 1 octets...
pas besoin d'un quad dans ce cas.

@++

Je ne suis pas tout à fait d'accord : une liste chaînée va forcément prendre plus de place qu'un tableau puisqu'il y a les pointeurs vers les éléments suivants/précédents.

Un tableau prend moins de place et est plus rapide qu'une liste chaînée donc si j'ai bien compris ?

Ollivier, tu peux expliquer plus en détail comment tu fais tes pseudo listes chaînées avec AllocateMemory() ? Comment tu fais pour insérer, supprimer, chercher un élément ?

pour stocker une grande quantité de donnée... j'utilise SQLite ou mysql

tout depend de tes besoins

comme la souligne Oliv un tableau représente un seul pointeur tandis qu'une chaîne possède un pointeur par ellement voir deux si on stocke le suivant et le précédent.

donc sur tes 12000 enregistrement tu peut gagner 12000*4~12000*4*2 octet en passant par les tableaux, tu aura aussi une gain en vitesse car on a plus besoin de lire 10 pointeur a partir du premier ellement pour accéder au dixième.

Pour sql Lite c'est simplement un fichier ou tes données vont être stocké et passer par la lib sql te permet de ne pas t'occuper de la façon dont les données sont enregistré. Ainsi par de simple requête (la il te faudra potasser un peu pour connaître toute les possibilité du sql) tu pourra récupérer, trier, ajouter , supprimer tes données. (par contre je suis pas sur que cela soit économique en terme de mémoire)

Bonjour à tous !

J'ai peur que vous partiez dans un faux problème !
Liste chainée ou espace mémoire dédié par AllocateMemory() c'est du kif kif. Il faut de toute manière avoir les octets en mémoire mais je ne vois pas ou est le problème avec aussi peu de donnée !

Calculons les besoins en mémoire :

12000 élements de 8 variables tout ceci2 fois et en admettant que chaque variable prend 100 octets (pas mal pour une variable !)

cela nous donne 12000*8*2*100 = 19 200 000 octets en parlant vite 19 Mo à l'époque où le moindre PC comporte 1 Go je ne vois pas le problème !

Mais c'est juste mon avis !

apres ca depend aussi sur quoi doit tourner le programme

mais je pense un peu comme brossden, 19 mo c'est pas grand chose

Le sujet portrait plutôt sur l'optimisation que sur la faisabilité !

Sinon 19Mo en mémoire juste pour les données sa commence a faire, dans ma liste de processus la seule chose qui arrive au dela c'est mon serveur X et firefox :p mais c'est vrai que cela reste dérisoire sur mes 1Go.

brossden a écrit :Bonjour à tous !

J'ai peur que vous partiez dans un faux problème !
Liste chainée ou espace mémoire dédié par AllocateMemory() c'est du kif kif. Il faut de toute manière avoir les octets en mémoire mais je ne vois pas ou est le problème avec aussi peu de donnée !

Calculons les besoins en mémoire :

12000 élements de 8 variables tout ceci2 fois et en admettant que chaque variable prend 100 octets (pas mal pour une variable !)

cela nous donne 12000*8*2*100 = 19 200 000 octets en parlant vite 19 Mo à l'époque où le moindre PC comporte 1 Go je ne vois pas le problème !

Mais c'est juste mon avis !

Ton raisonnement est juste !! ET moi je suis un IDIOT , je ne c'est pas pourquoi j'ai pu imaginé que mes listes chainée pouvait occuper autant de mémoire... En faites je viens de trouver le problème !!! Au démarrage de mon programme il y a environ 100 image qui sont charger!
C'est pour ça que j'arrive facilement à 100 Mo de mémoire j'aurai du y penser
D'ailleurs pour en avoir pour preuve qu'il ne s'agissait pas des listes chainée j'ai monter le nombre d'élément a 80 000 et la mémoire vive à a peine augmenté de 10Mo
Donc il s'agit des images que je charge au démarage...la j'ai un sérieux problème car les images j'en est besoin

Salut à tous,

Je suis d'accord avec la simplicité très terre à terre de calcul de Brossden.
Et c'est d'ailleurs avec ce raisonnement qu'on est contraint de réfléchir pour utiliser les blocs mémoire et les gérer.

En fait, les listes chaînées sont très bien pour la plupart des utilisations.
SAUF quand la taille de la structure de l'élément est petite. Or dans le cas du traitement de données massif, Fred ne peut pas répondre à tous nos besoins spécifiques : la structure interne d'un élément est actuellement élaborée pour répondre au mieux à ce qu'on attend couramment d'une liste chaîne. Et il en a fait l'instruction SortXXX().

Côté matériel, le CPU a une méthode de recherche extrêmement rapide mais très rigide, car elle se base sur la contigüité des données traitées. Le seul moyen de rendre les données compatibles à ce type de traitement c'est justement de fractionner chaque élément d'une pseudo-liste et de les classer par champ, voire de «sous-champ», voire plus précis encore selon les domaines d'utilisation de la base de données.

Pour illustrer, prenons l'exemple de la centrale de casse automobile (c'est la liste chaînée).

Il y a plein de voitures accidentées (éléments de la liste chaînée) dans tous les sens. Et vous avez recruté Superman pour bosser avec vous là-dedans. Superman, c'est l'instruction de recherche du CPU (j'ai posté une explication il y a qqes mois (rech >> SCASB, SCASW ou SCASD).

Un client arrive avec une voiture en panne : c'est le carburateur.
Vous ne pouvez pas demander à Superman d'aller chercher un carburateur comme ça. Il vous faut démonter TOUTES LES VOITURES et les classer par nature (je ne vous parle même pas de la «traçabilité» qu'il faut faire pour pouvoir les remonter ensuite). Ainsi, si vous avez 25 kilomètres de carburateurs différents qui se succèdent tous les 15 centimètres, Superman vous trouvera le carburateur très rapidement.

Cette technique n'est valable qu'avec les blocs mémoire. Et je pense que c'est sûrement la technique utilisée pour les puissants gestionnaires de base de données. Seulement, elle est très spécifique, donc à chaque type de recherche, il y a un type de classement. Elle n'est valable que dans le cas d'une multitude de recherches successives dans le même classement. Ce qui peut tout de même arriver fréquemment.

C'est la raison pour laquelle j'ai posté cette idée plus haut, en répondant à la question «n'y a-t-il pas une meilleure solution ?». Car, Neosis en sachant ce que tu as (type de données) et ce que tu veux (type de traitement), les listes chaînées peuvent s'avérer trop gourmandes en mémoire.

Maintenant, ton problème est ailleurs et réglé. Donc ceci est hors sujet.