Si tu as plusieurs petits fichiers à déplacer, je ne vois pas ce que tu peux optimiser. Il faut que tu les ouvres un par un en lecture d’un côté (ça a un coût système), que tu les ouvres en écriture de l’autre côté (idem, un peu supérieure), et que tu les lises et les écrives.

Le seul moment où on peut gagner en efficacité, c’est en utilisant des tampons pas trop petits (ça limite entre autres les appels système), surtout si le périphérique est rapide. Mais déjà avec des tampons de 64 k sous Linux on est quasi “à fond”, j’ai fait plus d’une fois le test avec des programmes maison (qui font quelque chose, pas juste un bench).

refuznik a écrit :



Tu verrais Nautilus sous Gnome pour la copie de gros fichiers ça rame comme pas possible.

Bon en ligne de commande ça passe direct. Mais Gnome a de gros problème là-dessus.





J’ai déjà vu un cas où une opération ramait parce que celui qui avait programmé le rafraichissement de la barre de progression le faisait comme un bourrin, sans tenir compte de la taille du fichier copié, donc à un rythme inutilement élevé : quand tu copies un fichier de 500 k, c’est pas grave si tu rafraichis tous les 4 k, mais pour la copie de 2 G, imagine le souci si tu le fais toujours à chaque 4 k, même si le “redraw” ne prend qu’une ms (ce qui en plus ne sert à rien vu qu’une granularité au % est souvent suffisante, soit pour 2 G environ tous les 20 M).







fred42 a écrit :



Aucun rapport visible entre les problèmes de perf de déplacement de fichiers entre périphériques USB et le lien que tu postes.





Exact, mais c’est peut-être la même chose pour la copie USB (problème de programmation qui a ralenti le bousin).

fred42 a écrit :



Et puis, au 21 ème siècle, on a le droit de faire des traitements asynchrones, la copie d’une part et l’affichage d’autre part.





Oui mais si l’affichage fait n’importe quoi (comme le genre de mauvaise programmation que j’indiquais), ça reste un souci, la barre de progression va rester affichée longtemps en progressant lentement.

Bon, si la copie est vraiment codée avec 2 parties asynchrones, avec un système correctement programmé, on peut espérer que la personne aura pensé à l’aspect rafraîchissement pas trop fréquent de l’interface.



Cela dit, quand tu fais un “scp”, c’est synchrone mais ça n’empêche pas de copier à fond (comme entre 2 de mes machines sur du Gb), parce que c’est codé correctement (“scp” ne met à jour l’affichage dans le terminal que toutes les secondes). Il n’y a pas besoin d’avoir un thread pour l’affichage et un pour la copie.