Bonjour je viens a vous car j'aimerai convertir mon code pour qu'il fonctionne en téléchargement en parallèle avec une seule progression global et les informations qui vont avec actuellement les téléchargements des fichiers est un peu lent malgré les 3Mo/s et je profite également pour savoir s'il y a des moyens d'optimisé celui-ci je cherche avant tout l'optimisation de mes codes donc si vous avec une remarque dessus n'hésitez pas.
Je sais que WebClient est obselète mais en utilisant HttpClient l'execution est saturé est non fluide.

Merci a ceux qui auront la patience de m'aider et de me conseiller!

R5GAMER.

-
Edité par R5GAMER 10 mars 2022 à 2:49:57

Pourquoi le multithreading ??

Utilisez les outils à jours et analysez le problème pour le corriger et pas inventer une solution au pif.

Sur le papier, un thread dédié au téléchargement et/ou les appels asynchrones serait en général plus simple et efficace.

Mon code présente aucun bug au contraire, il fonctionne parfaitement bien.

Je ne demande pas une solution au pif, je demande juste une aide pour améliorer mon code et avoir des avis sur l'optimisation de celui-ci ainsi qu'une solution pour qu'il télécharge plusieurs fichiers en même temps et non un par un d'où l'idée de le faire sur plusieurs "thread" tout comme ferai un parallel.ForEach peut être que je me suis mal exprimé sur ma question.

-
Edité par R5GAMER 6 mars 2022 à 22:00:48

>il fonctionne parfaitement bien.

Selon un cahier des charges qu'on vous a fourni ou qui a été créé de concert avec le client final ?

J'en doute, donc le "parfait" est superfétatoire et présomptueux, un programme n'est JAMAIS parfait, il doit répondre aux attentes actuelles et le plus possible aux attentes futures.

Pour améliorer votre code (ou plus précisément ces performances), on commence par analyser le problème, pas essayer un truc au pif, ou encore pire, demander sur un forum qu'un Olybrius vous donné SA solution à SON problème (ou ce qu'il a compris du problème du PO en ayant aucun informations pertinentes sur le problème du PO, autant consulter Mme Irma).

Ce qui est rédhibitoire dans votre code, aussi bien au niveau performance "crête" que maintenabilité, c'est le fait qu'il n'y a pas de frontière franche entre votre système de téléchargement, qui doit fonctionner même sans IHM, et votre GUI.

Votre GUI est, par design, mono-thread.

C'est OK pour un programme jouet, mais c'est hors de propos pour tout système "sérieux" de téléchargement.

Pourquoi réinventer une roue carrée ?

Alors déjà pour commencer il n'y a pas réellement de cahier des charges et ce n'est pas pour une entreprise.
C'est un projet solo dans lequel je suis en train de faire, je tente juste a m'amélioré en C#.
Quel méthode recommande tu pour corrigé et résoudre des problèmes tu as des liens me permettant de m'aider a les maîtriser ?
Je trouve que mon code n'est pas du tout performance dans le sens ou je lance trop de boucle en interne même si je termine le while (true) a la fin mais je l'ai mis dans le cas ou il échoue pour qu'il retente de le télécharger de nouveau, le deuxième problème vient aussi que je calcul trop dans la partie update tu aurai des astuces pour me permettre de réduire ces calculs ?

-
Edité par R5GAMER 7 mars 2022 à 20:17:10

>il n'y a pas réellement de cahier des charges et ce n'est pas pour une entreprise.

Un cahier des charges, c'est pas un document qui sert à facturer des prestation, c'est un truc qui permet de savoir quelle sont les attentes "objective" du bidule, donc rien à voir avec entreprise ou pas.

Sans ce cahier des charges, il est impossible de savoir qu'elle solution est "meilleure" qu'une autre. Même s'il n'y a pas d'erreur de programmation, il y a toujours plusieurs solution à un problème et sans cahier des charges, impossible de faire les choix "pertinents".

Donc on sait pas dans quelle "direction" vous voulez vraiment aller.

> C'est un projet solo

OK, bon, l'approche de créer une roue carrée peut se justifier pour l'apprentissage, mais si vous voulez vraiment faire des choses "sérieuses", commencez par évaluer TOUS les outils dont vous pouvez disposer, framework et solution tiers comprises.

>Quel méthode recommande tu

Sans cahier des charges, qui doit contenir une grille d'évaluation de la qualité des résultats de la solution selon un ensemble de critère "objectif", impossible de vous recommander une méthode plutôt qu'une autre.

Je ne peux que signaler les raccourcis de penser/raisonnement qui peuvent arriver à des résultats non conformes aux résultats supposément attendus.

Bin, mon conseil, un peu iconoclaste, comme d'hab., c'est dans faire le moins possible avec la meilleur maintenabilité possible : utiliser tout un framework et ensemble d'outils fait pour les téléchargement "en tâche de fond" : B.I.T.S.

https://docs.microsoft.com/fr-fr/windows/win32/bits/background-intelligent-transfer-service-portal

C'est beaucoup moins formateur sur l'apprentissage du langage XYZ mais bougrement plus efficace et "simple" (quand on a appris les technologies impliquées, mais aussi ça l'apprentissage, les langages, c'est le sommet de l'iceberg).

>Je trouve que mon code n'est pas du tout performance

Les performances, ça se mesure dans un cadre contrôlé, avec un profiler ; pas à "l'œil' ou "au doigt moillé".

Vos interrogations sont plus de l'ordre de la maintenabilité que de la performance.

>Je sais que WebClient est obselète mais en utilisant HttpClient

https://stackoverflow.com/questions/20530152/deciding-between-httpclient-and-webclient

Il y a pas photo, laissez tomber WebClient et apprenez à maitriser la "puissance" offerte pas HttpClient.

Les problèmes que vous décrivez avec l'usage de HttpClient ne sont pas étonnant, car il faut avoir une vue assez claire du modèle de threading du framework graphique que vous utilisez.

Les machins (parce que 'astuces', c'est un peu "présomptueux") que vous utilisez et que vous considérez comme des "problèmes de performance", c'est clairement de la rustine à 2 balles. Mais vous avez déjà l'avantage de "sentir" que c'est pas bon. (Heu, pour moi, ça sent déjà à un niveau de nauséabonditude bien trop insupportable pour que je puisse avoir un jugement pondéré : C'EST DE LA GROSSE MERDE, pardon.)

Le truc, c'est que pour imaginer ce genre de "bricolage", il faut avoir une vue assez claire du modèle de threading du framework graphique, que vous ne semblez pas avoir. Alors, n'utilisez jamais un bout de code que vous ne comprenez pas, jamais, ... enfin au moins un minimum.

Je suis assez embêter pour vous "conseiller" (oui, c'est ubuesque) un axe d'évolution. Moi, je dégagerai fissa ces bricolages à basse de boucle en utilisant "correctement" HttpClient (et particulièrement sans API asynchrone) .

Oui, j'ai l'impression que la mère de tous vos maux vient de l'usage de cette antiquité mal fichue de WebClient (qu'elle repose en paix, RIP).