En fait ça me travaille... Pourquoi est-ce que le fait d'appeller Read en ascynchrone augmente les performances.

Ca devrait être le contraire, vu qu'en async il faut générer le délégué, l'insérer dans le worker thread, l'exécuter, attendre que le delegué s'execute et récupérer les informations. Marcel une idée ?

Donc avec un buffer de 256ko au lieu de 64ko & des File.BeginRead() on passe à 42mo/sec.

Si en plus de ça on crée le FileStream à la main sans passer par le helper File.Open(), on peut lui indiquer qu'on va faire une lecture séquentielle pas aléatoire et on arrive à 50mo/sec et on est quasi aussi performant que le File.Copy().

Apparemment un début de réponse : http://stackoverflow.com/questions/1246899/file-copy-vs-manual-filestream-write-for-copying-file

Peut-etre que c'est le check des permissions qui est mis en cache dans la methode copy, tandis que tu te le retapes a chaque fois dans les read/write.

Hum voici une question existentielle qui me travaille...

- Lorsque je fais une copie depuis un de nos serveurs vers ma machine avec l'explorateur windows, j'ai une moyenne de 50mo/sec (j'ai vérifié ce n'est pas une erreur d'affichage.)

- Lorsque je fais la même copie avec supercopier, je suis à 25mo/sec.

J'ai donc sorti mon petit vs2008 pour essayer de comprendre et lorsque je fais une copie d'un fichier à la main File.Open() File.Read() File.Write() etc... j'ai aussi une vitesse de 25mo/sec. Par contre, si je passe par le System.IO.File.Copy(), je suis à 55mo/sec...

Qqun aurait-il une petite explication ? Parce que le System.IO.File.Copy(), c'est sympa mais pas de callback pour l'avancement de la copie