Discussion :

[Shypster]

Bonjour,

J'admet que le titre de mon sujet n'est pas trés explicite mais je n'ai pas trouvé autre chose.
En fait, je voudrais savoir si il est raisonnable de stocker la liste des fichiers à copier dans un objet List<string> pour ensuite les copier ?
Le nombre de fichiers dépendra du client qui exécutera le programme, on peut avoir 50000 fichiers comme 500000 voir +. Je ne voudrais pas que les ressources mémoire gonflent inoxérablement. Je pensais à une ressource externe allant d'un simple .txt jusqu'à une base de données sql.

Quelle est la meilleure stratégie surtout en terme de performance ? Je tiens vraiment à stocker le path des fichiers à copier.

Merci.

[ToshiroSama]

Une liste je veux bien mais la persistance elle est ou ?

500'000 accès disque pour écrire sur un fichier txt ... Bonjour les perf.

j'aurais utilisé un model de donnée, dbml,edmx.. ajouter mes lignes, et faire tout le traitement et puis a la fin, un commit des modifications. je crois qu'au niveau performance çà serait plus propre.

Model.ADDToMaTable(... x 500 000 + model.SaveChanges() [ par ex ] serait plus rapide que 500 000 écriture sur un fichier texte ou encore par rapport à 500 000 "insert".

Cela dit, ça m'accroche aussi, si il y'a d'autre solutions, je suis preneur.

[alexadvance]

Et pourquoi ne pas copier les fichiers un par un ?

Pour que ton utilisateur les choisissent, ils sont bien affichés quelque part ?
Donc, un par un, tu parcours les objets affichés et tu le copies.

[Pol63]

tu peux mettre autant de choses que tu veux dans un list<T>
enfin dans la limite d'un int32 (2 milliards environ)

et donc pour chaque élément que tu mets dedans ca va prendre 4 octets en mémoire (en plus de ce que tu mets dedans)
donc si tu mets 500 000 string, le list prendra 2Mo

après pour un string, peu importe dans quoi tu le stocks il prendra 2 octets par caractère

à l'instanciation tu peux spécifier la capacité prévue (genre 512 par défaut)
quand tu ajoutes un élément et que ca dépasse la capacité max, la liste est ré allouée dans un autre espace mémoire et la capacité est doublée (rien de bien grave, mais tant qu'à faire mettre une limite assez grosse ou bien évaluée)

[Shypster]

Une liste je veux bien mais la persistance elle est ou ?

500'000 accès disque pour écrire sur un fichier txt ... Bonjour les perf.

j'aurais utilisé un model de donnée, dbml,edmx.. ajouter mes lignes, et faire tout le traitement et puis a la fin, un commit des modifications. je crois qu'au niveau performance çà serait plus propre.

Model.ADDToMaTable(... x 500 000 + model.SaveChanges() [ par ex ] serait plus rapide que 500 000 écriture sur un fichier texte ou encore par rapport à 500 000 "insert".

Cela dit, ça m'accroche aussi, si il y'a d'autre solutions, je suis preneur.

Je ne cherche pas la persistance des données, je recrée la liste à chaque nouvelle copie.

PRINCIPE ACTUEL DU PROGRAMME :

Donc lors de l'analyze des fichiers que je fait à chaque nouvelle copie, je calcule le nombre de fichiers, la taille, je ne prends que les fichiers qui ont le bit d'archivage activé. C'est pendant cette analyse que je dois stocker les fichiers pour aprés les copier.

Je veux absolument stocker les fichiers car je m'appuierai dessus pour savoir quel fichier copier vu que le bit d'archivage est remis à zéro aprés chaque copie d'un fichier.

[hegros]

Si tu es en framework .NET 4 alors utilise plutôt plutôt les ListParallel dans l'espace System.Collection.Parallel car c'est plus performant que les List.

[Pol63]

jamais essayé les listparallel (que google ne connait pas avec cet orthographe d'ailleurs), mais si ca multithread les actions, avec la copie de fichiers c'est une mauvaise idée

m'enfin à mon avis le débat est clos
une list<T> de string ou meme d'une classe avec d'autres infos ne pose pas de soucis
nous en as plein avec toutes des 10aines de milliers d'instances dedans

[hegros]

jamais essayé les listparallel (que google ne connait pas avec cet orthographe d'ailleurs), mais si ca multithread les actions, avec la copie de fichiers c'est une mauvaise idée

Ce n'est pas listparallel..regarde plutôt dans l'espace System.Collection.Parallel. Et pourquoi c'est une mauvaise idée de paralléliser des copies de fichiers c'est très courant pour ne pas dire un cas d'école. Puis en terme de performance si tu as 500000 fichiers il faut obligatoirement passer par le threading pour gagner en performance car 1 seul thread il va avoir du mal.

m'enfin à mon avis le débat est clos
une list<T> de string ou meme d'une classe avec d'autres infos ne pose pas de soucis
nous en as plein avec toutes des 10aines de milliers d'instances dedans

A mon avis le débat est clos lorsque le sujet est tagué résolu

Le problème avec les List<T> c'est qu'elles ne sont pas optimisées pour des architectures multiprocesseurs ou multicores que les List du .NET 4 c'est une évidence