Application GUI critique en termes de performances (windows, linux)

https://stackoverflow.com/questions/9846

08-06-2019
|

Question

J'ai été chargé de mettre à jour une série d'applications VB.NET critiques en termes de performances, qui se contentent essentiellement de surveiller et de renvoyer des statistiques de mise en réseau.Je n'ai que trois exigences : convertissez-le en C#, rendez-le rapide et rendez-le stable

Une mise en garde est que nous "peut" migrer d'une plateforme .NET vers Linux "bientôt"

Je serai responsable de la maintenance de ces applications à l'avenir, j'aimerais donc bien faire les choses.J'ai décidé de refactoriser ces applications selon le modèle MVP afin de pouvoir tester correctement ce mauvais garçon.Mais je pensais aussi, depuis que j'utilisais MVP, que je pourrais également effectuer des tâches coûteuses en calcul dans du code C/C++ natif tandis que l'interface graphique serait réalisée avec des formulaires .NET, ou Qt ou autre.

des questions:

est-il logique de créer une interface graphique dans Winforms, mais les éléments coûteux en C/C++ natif et non géré ?
des recommandations pour un bon kit de fenêtrage multiplateforme qui conviendrait au scénario décrit ci-dessus ?

La solution

Tout d'abord, je consacrerais du temps à en essayer quelques-uns Convertisseurs VB.NET vers C#.Vous portez essentiellement la syntaxe, et il n’y a aucune raison de le faire à la main si vous n’y êtes pas obligé.Bien sûr, vous devrez peut-être nettoyer ce qui sort du convertisseur, mais c'est bien mieux qu'une conversion manuelle.

Maintenant, quant à vos questions :

1) est-il logique de créer une interface graphique dans Winforms, mais les éléments coûteux en C/C++ natif et non géré ?

Pas encore.Attendez d'avoir effectué la conversion, puis découvrez où vous passez réellement votre temps.Il n'y a aucune raison de se lancer dans le mélange de C/C++ avec C# jusqu'à ce que vous découvriez que c'est nécessaire.Vous constaterez peut-être que passer à un C# non sécurisé est suffisant.Même cela peut être inutile.Vous devrez peut-être simplement optimiser les algorithmes.Découvrez quels sont vos goulots d'étranglement et alors décidez comment les réparer.

2) des recommandations pour un bon kit de fenêtrage multiplateforme qui conviendrait au scénario décrit ci-dessus ?

j'examinerais mono à coup sûr.C'est vraiment le mieux que vous puissiez faire si vous utilisez C#.Il s'agit à peu près de mono ou d'une autre réécriture dans une autre langue lorsque/si vous passez à Linux.

Autres conseils

1) L’optimisation prématurée est mauvaise.Implémentez vos « trucs coûteux » en C# et voyez si vous devez les refactoriser.Ou, au moins, mettez en place un test qui vous permettra de le déterminer.

2) Beurk.Interface utilisateur multiplateforme.Je ne supporterais pas les trucs du "mai".Clouez les belettes;Comment pouvez-vous prendre des décisions de conception sans savoir ce que vous concevez ?Si vous optez pour une implémentation pure .NET, se plaindront-ils si vous devez (au minimum) la refactoriser pour qu'elle fonctionne dans Mono ?Si vous le créez en Java, seront-ils ennuyés par le fait que cela semble moche et que les utilisateurs se plaignent de ne pas trouver leur fichier .exe parmi tous ces .jars ?

1) Pas nécessairement.Je pense qu'il serait plus correct de dire qu'il vaut probablement la peine d'écrire votre code backend en C++, quelles que soient les implications en termes de performances.Même si vous ne pouvez pas attacher vos supérieurs au changement de plate-forme, il serait prudent de votre part de vous préparer à cette éventualité, car les types de gestion ont tendance à changer d'avis sans raison valable (ou avertissement) ;même s'ils décident de ne pas changer maintenant, cela ne veut pas dire qu'ils ne décideront pas de changer dans six mois.Écrire votre logique en C++ maintenant, sachant que c'est une possibilité, bien que plus difficile, peut vous rendre la vie beaucoup plus facile plus tard.

2) Pas vraiment.Il existe des "solutions" comme wxWindows et GTK#, mais elles sont souvent boguées, ou difficiles à faire fonctionner correctement, ou il leur manque quelque chose d'important sur une plate-forme ou une autre.Ils vous enferment également généralement dans une interface utilisateur au plus petit dénominateur commun (c'est-à-dire que les contrôles généraux fonctionnent bien mais vous pouvez oublier de faire quelque chose d'intéressant - WPF, par exemple - avec).Les interfaces utilisateur sont faciles à écrire, donc je pense que si vous écrivez votre logique dans quelque chose de portable, il devrait être simple de regrouper plusieurs interfaces utilisateur spécifiques à une plate-forme.

Pour la première question, il est très difficile de dire si cela aurait du sens, car cela dépendrait probablement du type de performances que vous souhaitez obtenir.Personnellement, je n'ai vu aucun ralentissement à l'échelle du système dû à l'interface graphique dans des interfaces graphiques correctement conçues utilisant WinForms, donc je ne vois pas pourquoi cela devrait causer des problèmes, et selon toute vraisemblance, cela vous faciliterait la vie en ce qui concerne l'interface graphique. .

Quant à votre deuxième question, si vous envisagez de migrer vers une autre plate-forme à un moment donné, vous souhaitez jeter un œil aux bibliothèques qui ont été implémentées par Mono (http://www.mono-project.com/Main_Page), cela devrait également couvrir la plupart de vos besoins en matière de fenêtrage multiplateforme car il prend en charge WinForms et GTK#.

Non, cela n'a pas de sens de faire des « trucs coûteux » en C/C++.Les améliorations potentielles (et très probablement mineures) des performances ne dépassent jamais votre productivité, étant une blague abjecte et malade par rapport à C#.Vraiment.Ce n'est même pas proche.

Lisez ceci (et tous les articles référencés à l’intérieur) :http://blogs.msdn.com/ricom/archive/2005/05/10/416151.aspx

Vous voudrez peut-être envisager d'utiliser Mono.Il s'agit d'une version open source de .NET qui fonctionne sur de nombreuses plateformes... Linux, Mac, Solaris, Windows, etc.

Parlons maintenant du codage de vos éléments coûteux en C/C++.Voici un article qui fait un très bon travail expliquant les différences entre Performances C/C++ et C#.

Et encore une fois, permettez-moi de souligner que les éléments C++ sont très chers.Serait-il judicieux de faire ce que j'ai mentionné ci-dessus ?(Formulaires .NET cachant du C++ lourd)

Comme indiqué précédemment, je n'ai personnellement remarqué aucun ralentissement à l'échelle du système dû à WinForms dans les applications écrites à la fois en VB.NET et en C#.Cependant, si l'application est vraiment gourmande en performances, vous remarquerez peut-être un léger ralentissement si vous avez tout écrit en C# en raison de sa conformité avec CIL (http://www.cl.cam.ac.uk/research/srg/han/hprls/orangepath/timestable-demo/).En tant que tel, écrire l’interface graphique dans un langage tel que C# facilitera probablement un peu cette partie du développement, ce qui vous donnera plus de temps pour travailler sur les parties critiques du code.Le seul piège ici est que vous remarquerez peut-être des ralentissements dus aux appels au code C/C++ à partir du code C# ;cependant, cela est probablement très improbable.

1) est-il logique de créer une interface graphique dans Winforms, mais les éléments coûteux en C/C++ natif et non géré ?

Préférablement pas.À moins que vous ne communiquiez avec de nombreuses autres DLL C natives, C# est susceptible d'être entre 5 % et 5 % plus lent. plus rapide que C++ (std::string vous tue vraiment si vous l'utilisez)

2) des recommandations pour un bon kit de fenêtrage multiplateforme qui conviendrait au scénario décrit ci-dessus ?

S'il ne s'agit que de quelques formulaires simples avec des boutons, mono pourra probablement les exécuter sans modification.La prise en charge de .NET WinForms est plutôt bonne de nos jours.Mais c'est moche :-)

Je n'ai peut-être pas compris le problème, mais s'il s'agit d'un système de surveillance réseau, pourquoi n'est-il pas écrit comme un service Windows « dédié » ?

VB.NET ne devrait pas être beaucoup plus lent que C#.Je ne suis pas sûr à 100% s'il y a de grandes différences dans le code IL généré, mais le seul avantage (et la raison justifiable de le réécrire en C#) auquel je pourrais penser (sauf que C# a une syntaxe plus agréable et quelques autres avantages ) est l'utilisation d'un bloc de code non sécurisé qui pourrait accélérer un peu les choses.

Les trucs c/c++ peuvent finir par être une bonne idée, mais pour le moment, YAGNI.Pareil avec les trucs Linux.Ignorez-le, tu n'en auras pas besoin jusqu'à ce que vous en ayez besoin.Garde le simple.Testez l'unité à fond, comme vous le dites.Faites fonctionner le code et faire évoluer le design De là.

J'ai eu un dilemme similaire il y a quelque temps, alors que j'essayais de trouver le meilleur moyen de développer un outil de test matériel sur PC (ce qui signifie évidemment "avec des options d'interface utilisateur") qui interagit avec un matériel embarqué (via l'interface PCMCIA).

Le goulot d'étranglement était que les tests devaient s'exécuter avec un écart maximum de 10 ms par rapport à la durée prévue spécifiée par le testeur.

Par exemple:Si le testeur crée la séquence de test suivante :

le délai mentionné à l'étape 2 ne doit pas être > 60 ms.

J'ai choisi l'application C++ WIN32 comme back-end et VC++ 2005 Winform (plateforme .NET) pour le développement de l'interface utilisateur.Des informations détaillées sur la manière d'interfacer ces deux éléments sont disponibles dans msdn
J'ai séparé le système comme ceci :
Dans VC++ .NET :

En C++ WIN32 :

Le système complet est opérationnel.Cela semble assez stable.(Sans l'écart de timing mentionné ci-dessus).
Notez que le PC de test que nous utilisons est uniquement destiné aux tests matériels (il y avait juste l'interface utilisateur en cours d'exécution, sans mises à jour automatiques, analyse antivirus, etc.etc..).

gtk-sharp est une très belle boîte à outils multiplateforme.

Gtk# est une boîte à outils d'interface utilisateur graphique pour mono et .Net.Le projet lie la boîte à outils gtk+ et un assortiment de bibliothèques GNOME, permettant le développement d'applications graphiques Gnome entièrement natives à l'aide des frameworks de développement Mono et .Net.

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow