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

[Pol63]

et bien je suis désolé, mais sur un disque dur classique, même un sas à 15000 tours minutes, il ne faut surtout pas paralléliser la copie des fichiers (sur un ssd il faudrait tester)

le multi threading sert à gagner du temps sur l'utilisation du processeur
pendant la copie d'un fichier le processeur ne sert à rien
et surtout, quand le disque dur doit déplacer sa tête d'un endroit à un autre il peut se prendre jusqu'à 20 millisecondes de latence
donc copier 10 fichiers en meme temps va allourdir la copie (sur un lecteur optique c'est encore pire)

tu peux faire le test dans windows, tu copies deux fichiers d'1Go chacun environ chacun leur tour et la même chose mais les 2 en même temps, et tu verras que chacun son tour ca va plus vite !
d'ailleurs tous les copieurs font ca, même la copie depuis windows avec une sélection de plusieurs fichiers va les traiter un par un


et puis on pouvait faire du multithreading sur les collections avant le framework 4, c'est juste que c'est plus simple à écrire

[Invité]

le multi threading sert à gagner du temps sur l'utilisation du processeur
pendant la copie d'un fichier le processeur ne sert à rien
et surtout, quand le disque dur doit déplacer sa tête d'un endroit à un autre il peut se prendre jusqu'à 20 millisecondes de latence
donc copier 10 fichiers en meme temps va allourdir la copie (sur un lecteur optique c'est encore pire)

Totalement d'accord avec toi

d'ailleurs tous les copieurs font ca, même la copie depuis windows avec une sélection de plusieurs fichiers va les traiter un par un

très juste

[hegros]

Beh moi quand je fais des copier/coller depuis l'explorateur windows je lance plusieurs copies en même temps et toutes les copies évoluent en parallèles et pas au tour à tour sinon cela ne sert rien de pouvoir le faire.

Ensuite les disques dur à têtes c'est le moyen âge et ce n'est pas forcément sur un disque dur que tu fais une copie cela peut-être dans une mémoire sans une grosse tête mécanique cela peut être une mémoire de masse électronique.

Puis .NET 4 c'est optimisé pour gérer ces choses là. On n'a pas à se soucier si la copie est faite sur un support qui utilise encore un vieux système mécanique à tête de lecture,de l'électronique, optique ou autre chose. Justement dans .NET 4 il va récupérer toutes ces informations et effectuer ce qui est le plus optimisé et rapide donc soit une copie avec un ou plusieurs threads

Ce sont quand même des cas d'écoles. Lance 1million de copie dans un seul thread puis lance 1 million avec le bon nombre de thread qu'il faut il n'y a même pas photo sur les performances sinon autant dire que tout le système de threading de sql server ne sert à rien..

et puis on pouvait faire du multithreading sur les collections avant le framework 4, c'est juste que c'est plus simple à écrire

sauf qu'en .NET 4 c'est plus optimisé parce qu'entre temps les processeurs ont évolué et vont encore évolué de même que les mémoires de masse cependant c'est aussi plus simple à écrire.

[Pol63]

des abominations

joli troll, un beau ramassi de conneries !
on est pourtant pas le 1er avril ...

[hegros]

joli troll, un beau ramassi de conneries !
on est pourtant pas le 1er avril ...

oui oui biensûr reste avec ton vieux framework 1.1, ton ms-dos et ton disque avec tes têtes de lectures mécanique de l'époque de cromagnon

[Shypster]

Ok merci, je vais me pencher sur un simple List<T>, c'est le cas moins prise de tête tout en restant une solution raisonnable apparemment.

Merci à vous tous.

[Pol63]

Beh moi quand je fais des copier/coller depuis l'explorateur windows je lance plusieurs copies en même temps et toutes les copies évoluent en parallèles et pas au tour à tour sinon cela ne sert rien de pouvoir le faire.

tu peux le faire plusieurs en meme temps, mais ca prend plus de temps
essaye comme je te l'ai dis de faire un test, moi je l'ai fait pensant que ca allait au mieux prendre le meme temps, mais ca en prend plus
et puis même avec un ssd ca ne peut pas aller plus vite, si le ssd peut lire x Mo/s, il ira à cette vitesse sur un fichier et la vitesse sera divisée par 2 pour la lecture de 2 fichiers

Ensuite les disques dur à têtes c'est le moyen âge et ce n'est pas forcément sur un disque dur que tu fais une copie cela peut-être dans une mémoire sans une grosse tête mécanique cela peut être une mémoire de masse électronique.

90% des disques dur vendus en ce moment sont des disques magnétiques avec une tête de lecture qui se déplace, seul la mémoire flash (clé usb, ssd) n'a pas de tête
et puis un fichier c'est forcément sur du stockage (donc souvent sur un disque dur) sinon ce n'est plus un fichier, il y a pas de table d'allocation des fichiers dans la ram !

Puis .NET 4 c'est optimisé pour gérer ces choses là. On n'a pas à se soucier si la copie est faite sur un support qui utilise encore un vieux système mécanique à tête de lecture,de l'électronique, optique ou autre chose. Justement dans .NET 4 il va récupérer toutes ces informations et effectuer ce qui est le plus optimisé et rapide donc soit une copie avec un ou plusieurs threads

le framework 4 n'apporte pas plus de rapidité sur le multithreading que le framework 2, il y a juste une simplification d'écriture

Ce sont quand même des cas d'écoles. Lance 1million de copie dans un seul thread puis lance 1 million avec le bon nombre de thread qu'il faut il n'y a même pas photo sur les performances sinon autant dire que tout le système de threading de sql server ne sert à rien..

et bien essaye toi, tu verras que tu dis des conneries
et puis sql server a une centaine de thread certes mais un seul pour écrire sur le disque, il ordonne même ce qu'il va écrire pour diminuer le déplacement des têtes, et ca c'est microsoft qui le dit


bref je confirme tu dis vraiment nimp

[hegros]

tu peux le faire plusieurs en meme temps, mais ca prend plus de temps
essaye comme je te l'ai dis de faire un test, moi je l'ai fait pensant que ca allait au mieux prendre le meme temps, mais ca en prend plus
et puis même avec un ssd ca ne peut pas aller plus vite, si le ssd peut lire x Mo/s, il ira à cette vitesse sur un fichier et la vitesse sera divisée par 2 pour la lecture de 2 fichiers

Il faut que tu apprennes à écrire des vrais tests. Tu prends 2 fichiers au hasard et tu tires des conclusions. Bref, que des affirmations péremptoires je n'ai aucune raison de donner 1 centime de crédit à ce genre d'arguments sorti du chapeau.

90% des disques dur vendus en ce moment sont des disques magnétiques avec une tête de lecture qui se déplace, seul la mémoire flash (clé usb, ssd) n'a pas de tête
et puis un fichier c'est forcément sur du stockage (donc souvent sur un disque dur) sinon ce n'est plus un fichier, il y a pas de table d'allocation des fichiers dans la ram !

Justement on s'en fout qu'il y a une table d'allocation fichiers ou pas. Puis aujourd'hui ok c'est 90% mais tu n'arrives pas à comprendre que demain (disons dans 3 ou 4 ans pour le ssd) cela ne sera plus le cas. Donc ta façon de penser sera obsoléte ou en tout cas tes arguments.

le framework 4 n'apporte pas plus de rapidité sur le multithreading que le framework 2, il y a juste une simplification d'écriture

Si puisque toute la conception a changée ce n'est plus géré dans un simple threadpool. Il y a pleins d'optimisations qui ont été faite relis mon n'importe quoi d'hier. Avec .NET 4 c'est le manager qui en fonction des paramètres (disque à tête de lecture ou pas, nombre de core ou processeur etc etc etc) détermine le nombre de thread à lancer. Lis un livre avant de dire n'importe quoi.

et bien essaye toi, tu verras que tu dis des conneries
et puis sql server a une centaine de thread certes mais un seul pour écrire sur le disque, il ordonne même ce qu'il va écrire pour diminuer le déplacement des têtes, et ca c'est microsoft qui le dit


bref je confirme tu dis vraiment nimp

oui oui sauf que moi contrairement à toi mes tests ce n'est pas de prendre 2 fichiers de 1 GO et tirer des conclusions la dessus.


Allez amuse toi bien avec ton ms dos, ton framework 2 et tes disques mécaniques.

[Pol63]

non mais sérieux tu es en plein délires

dire que dans 5 ans les disques durs pourraient faire du multi accès simultanné, peut etre, mais il n'y a aucun actuellement qui peut le faire sans perte de performance (même pas un ssd)

donc répondre à un topic de copie de fichier en 2010 en disant qu'il faut multithreader la copie c'est totalement idiot

de plus si une classe du framework 4 gère la copie multithreadé de fichiers en analysant le type de disque je veux bien que tu me donnes son nom (je t'avance, tu ne la trouveras pas)
parce que ce n'est en tout cas pas une collection qui va deviner que les string que tu les mets dedans sont des fichiers que tu vas copier

[hegros]

Ce que je dis c'est que les disques dur mécanique vont être d'une autre époque c'est tout et que cela dans l'absolu m'est égal car j'ai pas besoin de savoir si j'écris dans un disque mécanique ou une mémoire flash je m'en fous complètement.

Non ce n'est pas idiot de multithreadé la copie de fichier ce sont des cas d'écoles et c'est très répandu comme pratique. Mais toi manifestement si tu as 1 million de fichiers à copier un seul thread te suffit. Beh super tu fais un programme avec un seul thread et moi avec plusieurs threads tu verras que tu seras à la ramasse.

Non la liste ne sait pas que tu vas faire des copies de fichiers cependant si tu optes pour utiliser le multithreading sur une liste alors celle du .NET 4 est plus optimisé c'est tout.