Version imprimable
Bonjour,
Est-il vrai que les applications Qt sont "sensiblement" (ou très sensiblement) moins réactive que les applications MFC dû à une surcouche logicielle?
Quand je dis sensiblement, il faut bien prendre ça avec des pincettes, j'entends par là que ici et là on arrive à percevoir des latences ou temps de réactions qui seraient moindre avec une GUI MFC.
Merci
Bonjour
MFC n'est pas elle même une surcouche logicielle ? (je ne connais pas)
Dans le passé, on reprochais parfois (souvent ?) aux frameworks en général d'être moins réactif que la programmation native. Je pense que ce n'est plus le cas actuellement et que la différence n'est pas perceptible (sauf dans le cas de programmation avec les pieds).
Qt bénéficie également de la volonté de Nokia de le porter sur les téléphones mobiles (donc ayant de faibles capacités) sans perte de performances. Il suffit de voir les récentes publications sur les tests de performances de Qt (Qt Graphics & performances).
Bref, à utiliser sans risque (sauf dans un certain nombre de cas particulier, où il faudrait vérifier les performances : embarqué, IHM très lourde, etc.)
par exemple je compare deux logiciels de poker pokerstars et full tilt poker
pokerstars est fait en MFC full tilt poker en Qt, la première est beaucoup plus réactive que la deuxième....
Aucune chance que cela vienne du code du programme et non de la lib utilisée ?
Plus sérieusement, tu ne peux pas comparer 2 frameworks (surtout aussi complet que Qt et MFC) en te basant sur 2 logiciels. Fais des benchmarks pour vérifier que la différence de performances (et surtout vérifier que cette différence est significative et perceptible).
C'est censé être la version en C/C++ (ou C with classes, quelque part entre les deux) de l'API Win32.Citation:
Envoyé par gbdivers
La différence, c'est surtout que le premier, le développeur s'est suicidé après la première version du programme. Pour le deuxième, il vit encore.Citation:
Envoyé par guillaume07
Sinon, je veux bien venir comparer les deux comme ça... C'était sur la même machine ? Avec la même charge ? C'était tous deux des devs compétents ? Ils connaissaient tous deux ce qu'ils utilisaient ? Aucun des deux n'était dépressif ?
Viens comparer Bing et Google en termes de performances : ils ne te donneront déjà pas les mêmes résultats, le premier fonctionne sur des technologies dotnet, le second sur du Python, ils n'ont pas du tout la même mécanique interne, etc. Viens comparer le comparable ;).
Si tu veux que ton application soit vraiment plus réactive, il faut passer les calculs les plus lourds et parallélisables sur le GPU (OpenGL pour l'affichage ; CUDA ou OpenCL pour le reste), que tout soit calculé sur le matériel qui est prévu pour les calculs, etc. Si tu dois dessiner des fractales, par exemple, ni les MFC ni Qt ne te permettront d'avoir des GUI réactives sur toutes les bécanes, peu importe ton niveau, si tu te limites aux techniques "normales" de calcul. Mets tout ce qui est lourd sur du matos prévu pour dégommer les calculs de polybourrins et tu verras que tout ira mieux, le CPU pourra se limiter de récupérer les infos précalculées, il n'aura qu'à ajouter deux-trois widgets au-dessus et c'est bon pour l'utilisateur. Mais c'est sortir la grosse arme pour être sûr que tout avance trsè bien. Très peu d'applications ont besoin d'autant de puissance brute (calculs mathématiques compliqués, traitement d'images brutes de taille importante comme l'imagerie médicale, etc.).
ok donc selon vous Qt n'a aucune penalty par rapport aux MFC, c'est bien ça que vous soutenait ?
Très exactement. En plus, avec Qt, tu peux faire de belles animations très fluides sans souci ; avec les MFC, tu peux en faire d'une manière très compliquée donnant un résultat au final ne valant pas le temps passé à le faire.
Je ne serais pas aussi catégorique puisque je ne connais pas MFC mais je sais que je n'ai jamais eu de problème avec des IHM complexes avec beaucoup de widgets et des animations en Qt.Citation:
ok donc selon vous Qt n'a aucune penalty par rapport aux MFC, c'est bien ça que vous soutenait ?
J'imagine que MFC peut être plus performant que Qt sur certains points (les développeurs de MFC ne doivent pas être des manchots non plus) mais cette différence est négligeable.
Pour ma part je distinguerai deux choses, GUI et métier :
GUI : Pas de différence notable je pense car pour que tu le voies il faudrait que ça prenne disons plus de 20ms (100?) et pour le proço 10ms c'est énorme, il a de quoi faire des millions de cycles pendant ce temps là.
Métier : ton programme va faire autre chose probablement que du gui, le gui n'est là que pour l'interfaçage. Et pour le code métier, je pense que les classes QVector, QList ou autres classes utiles n'ont rien à envier à la std lib. Mais il faut aussi les utiliser correctement.
Ce qui peut faire que ça donne l'impression que ça rame est la manière dont c'est programmé, agencé par le dév. Le framework changera pas grand chose. Il faudra par exemple exécuter les tâches lourdes dans un thread en tache de fond pendant que la gui reste rapide...
ok disons qu'on voit tout de même de manière assez récurrente dans les roads maps , la volonté de vouloir amélioré les performances, et pour ma part ayant fait un peu moins de 2 ans de MFC et 2 ans de Qt, c'est le sentiment que j'avais mais impossible de trouver un bench sur le net
Du coup, j'ai du mal à comprendre l'intérêt de votre question initiale, si vous avez déjà une opinion sur le sujet, basée sur une "grosse" expérience avec ces frameworks (probablement plus que beaucoup d'intervenant ici).Citation:
pour ma part ayant fait un peu moins de 2 ans de MFC et 2 ans de Qt, c'est le sentiment que j'avais
Vous ne semblez pas croire les autres opinions sur les performances de Qt (ce que je peux comprendre puisque ce ne sont que des opinions et non des preuves) mais dans ce cas pourquoi demander l'opinion des autres ? Il aurait peut être fallut commencer votre message par "Je suis expérimenté avec Qt et MFC et j'ai observé que Qt est moins réactif. Avez-vous des benchmarks montrant le contraire ?"
Ça aurait évité qu'on donne notre opinion pour rien.
Bonne continuation quand même
je voulais en plus d'un éventuel benchmark " cas optimal " avoir l'avis des intervenants régulier de ce forum. J'ai pensé qu'en ne donnant pas cette information (Xp avec les 2 frameworks) j'aurais plus de chance de récolter l'avis "authentique" de ces derniers.
Cordialement