Bonjour,
Je vais refaire une grande partie de mon travail car j'ai mal choisi
les structures des donn=E9es car les acc=E8s fichiers sont plus co=FBteux.
Tout mon travail se base sur les fichiers m=EAme les r=E9sultats
interm=E9diaires. Le but de mon travail est de trouver une solution =E0
mon probl=E8me mais de plus minimiser le plus possible le temps
d'ex=E9cution.
Mais, lorsque j'ai test=E9 le temps de l'ex=E9cution CPU concernant la
comparaison de deux fichiers selon les crit=E8res bien d=E9finis alors
j'ai remarqu=E9 que le temps est devenir tr=E8s longue si nous avons des
fichiers avec des centaines lignes.
On va lire chaque ligne de fichier 1 et le compare avec tous les
lignes de fichier 2. C'est tr=E8s couteux.
D'apr=E8s vous :
- Avec quelles structures des donn=E9es ces deux fichiers seront
remplac=E9s ?
- En g=E9n=E9ral,quelle est la structure des donn=E9es la moins couteuse en
m=E9moire et donc temps CPU le plus inf=E9rieur possible ?
Je souhaite que vous m'aidez et je n'oublierai pas votre assistance.
On 4 nov, 10:04, Bertrand Lenoir-Welter <bertrand-dot-2008-at-galaad- dot-net> wrote:
Pour les performances, à moins de faire sans cesse des recherches sur u n élément, vous ne verrez pas trop la différence. Personnellement, j' ai un gros faible pour les listes chaînées qui ont une souplesse que rien n'égale
Oui, les listes chainées, c'est souple et recommandé pour les petits volumes Mais ça devient très lent pour les gros volumes (dizaines ou centaines de milliers d'éléments) Et je pense que l'OP n'a que des petits volumes vu les exemples donnés..
On 4 nov, 10:04, Bertrand Lenoir-Welter <bertrand-dot-2008-at-galaad-
dot-net> wrote:
Pour les performances, à moins de faire sans cesse des recherches sur u n
élément, vous ne verrez pas trop la différence. Personnellement, j' ai un
gros faible pour les listes chaînées qui ont une souplesse que rien
n'égale
Oui, les listes chainées, c'est souple et recommandé pour les petits
volumes
Mais ça devient très lent pour les gros volumes (dizaines ou centaines
de milliers d'éléments)
Et je pense que l'OP n'a que des petits volumes vu les exemples
donnés..
On 4 nov, 10:04, Bertrand Lenoir-Welter <bertrand-dot-2008-at-galaad- dot-net> wrote:
Pour les performances, à moins de faire sans cesse des recherches sur u n élément, vous ne verrez pas trop la différence. Personnellement, j' ai un gros faible pour les listes chaînées qui ont une souplesse que rien n'égale
Oui, les listes chainées, c'est souple et recommandé pour les petits volumes Mais ça devient très lent pour les gros volumes (dizaines ou centaines de milliers d'éléments) Et je pense que l'OP n'a que des petits volumes vu les exemples donnés..
Bertrand Lenoir-Welter
> Oui, les listes chainées, c'est souple et recommandé pour les petits volumes Mais ça devient très lent pour les gros volumes (dizaines ou centaines de milliers d'éléments)
J'ai des listes chaînées avec parfois des centaines de milliers d'éléments et je trouve pas ça si lent. Ca dépend de ce qu'on a à faire dedans. De toute façon, quand on ne sait pas à l'avance s'il y aura 1 ou 100 000 éléments à stocker, je vois mal un tableau.
> Oui, les listes chainées, c'est souple et recommandé pour les petits
volumes
Mais ça devient très lent pour les gros volumes (dizaines ou centaines
de milliers d'éléments)
J'ai des listes chaînées avec parfois des centaines de milliers
d'éléments et je trouve pas ça si lent. Ca dépend de ce qu'on a à faire
dedans. De toute façon, quand on ne sait pas à l'avance s'il y aura 1 ou
100 000 éléments à stocker, je vois mal un tableau.
> Oui, les listes chainées, c'est souple et recommandé pour les petits volumes Mais ça devient très lent pour les gros volumes (dizaines ou centaines de milliers d'éléments)
J'ai des listes chaînées avec parfois des centaines de milliers d'éléments et je trouve pas ça si lent. Ca dépend de ce qu'on a à faire dedans. De toute façon, quand on ne sait pas à l'avance s'il y aura 1 ou 100 000 éléments à stocker, je vois mal un tableau.
