Qu'est-ce qui cause de mauvaises performances dans les applications grand public? [fermé]

Mon DVR Comcast prend au moins trois secondes pour répondre à chaque pression de touche de la télécommande, ce qui fait de la simple tâche de regarder la télévision une expérience frustrante de purge des boutons. Mon iPhone prend au moins quinze secondes pour afficher les messages texte et se bloque ¼ des fois où j'essaie d'appeler l'application iPod; la simple réception et lecture d'un e-mail prend souvent plus d'une minute. Même le navcom dans ma voiture a des commandes pâteuses et qui ne répondent pas, avalant souvent des entrées successives si je les fais à moins de quelques secondes d'intervalle.

Ce sont tous des appareils grand public à matériel fixe pour lesquels la convivialité doit être primordiale, et pourtant ils échouent tous à la réactivité et à la latence de base. Leur logiciel est tout simplement trop lent .

Qu'est-ce qui se cache derrière ça? S'agit-il d'un problème technique ou social? Qui ou quoi est responsable?

Est-ce parce que ceux-ci ont tous été écrits dans des langues gérées et récupérées plutôt que du code natif? Est-ce les programmeurs individuels qui ont écrit le logiciel pour ces appareils? Dans tous ces cas, les développeurs d'applications savaient exactement quelle plate-forme matérielle ils visaient et quelles étaient ses capacités; n'en ont-ils pas tenu compte? Est-ce le type qui répète "l'optimisation est la racine de tout mal", les a-t-il égarés? Était-ce une mentalité de "oh c'est juste 100 ms supplémentaires" à chaque fois jusqu'à ce que toutes ces millisecondes ajoutent des minutes? Est-ce ma faute, pour avoir acheté ces produits en premier lieu?

C'est une question subjective, sans réponse unique, mais je suis souvent frustré de voir autant de réponses ici disant "oh, ne vous inquiétez pas de la vitesse du code, les performances n'ont pas d'importance" alors que clairement à un moment donné, cela compte pour l'utilisateur final qui se retrouve coincé avec une expérience lente, sans réponse, horrible.

Alors, à quel moment les choses ont-elles mal tourné pour ces produits? Que pouvons-nous faire en tant que programmeurs pour éviter d'infliger cette douleur à nos propres clients?

Bonne question. Ce que je vois quotidiennement, c'est ceci.

Les gens travaillent sur des applications de bonne taille. Au fur et à mesure qu'ils fonctionnent, des problèmes de performances se glissent, tout comme les bogues. La différence est - les bogues sont "mauvais" - ils crient "trouvez-moi et corrigez-moi". Les problèmes de performance restent là et s'aggravent. Les programmeurs pensent souvent "Eh bien, mon code n'aurait pas de problème de performances. La direction doit plutôt m'acheter une machine plus récente / plus grande / plus rapide."

Le fait est que si les développeurs recherchent périodiquement des problèmes de performances (ce qui est en fait très facile ), ils pourraient simplement les nettoyer.

Au lieu de cela, «l'état de l'art» est:

1. s'appuyer sur des aphorismes comme «éviter l'optimisation prématurée» et 90/10 hoo-haw.
2. parler courageusement du profilage et parfois l'essayer, souvent avec des résultats décevants, comme vous le voyez dans toutes les questions SO à ce sujet.
3. retomber sur une bonne vieille conjecture, déguisée en expérience et en connaissance.

Mais vraiment, c'est négatif. Pour être positif, cette méthode fonctionne presque tout le temps, et cela ne pourrait pas être plus simple. Voici un exemple détaillé .

Ce n'est pas un problème technique, c'est un problème de marketing et de gestion.

Vous pouvez rouler des yeux à ce stade, mais soyez indulgent avec moi.

Ce qu'une entreprise vend, c'est son "produit", et les gens qui définissent ce que c'est sont des "chefs de produit". Dans les entreprises technologiques, beaucoup d'autres personnes y pèsent - des experts en expérience utilisateur, yadda yadda. Mais en fin de compte, les responsables de produit sont chargés d'écrire les spécifications de ce que l'utilisateur est censé obtenir.

Prenons donc votre DVR Comcast. Idéalement, les choses fonctionneraient comme ceci:

1. Le chef de produit écrit dans une spécification: "Lorsqu'un utilisateur appuie sur un bouton de la télécommande et se trouve à moins de 25 pieds du DVR, le DVR doit répondre à la presse dans les 250 millisecondes".
2. Les techniciens construisent le matériel, écrivent le logiciel embarqué, etc.
3. Les testeurs QA approuvent soit la conformité du système aux spécifications, soit le renvoient à l'équipe technique pour un correctif.

Bien sûr, beaucoup de choses peuvent mal tourner:

• Le chef de produit ne parvient pas à mettre la réponse du bouton dans la spécification
• Les gens de QA font un travail médiocre de test par rapport à la spécification
• Quelqu'un a sélectionné des technologies qui ne permettent pas de respecter la spécification, de sorte que l'exigence est renvoyée
• Le personnel technique est à court de personnel, ou quelqu'un a accéléré le calendrier, et un gestionnaire dit: "Oubliez la réactivité - finissez cette autre fonctionnalité."
• Le chef de produit ne publie l'exigence de réactivité que si tard dans le jeu, elle ne peut pas être satisfaite à la date d'expédition
• La direction décide de ne rien soumettre aux tests d'assurance qualité jusqu'à si tard, l'accélération du code lent déstabiliserait le produit

Avez-vous vu tous les programmeurs irréfléchis là-dedans? Il n'y en avait pas.

Je ne dis pas que nous n'assumons aucune responsabilité pour les mauvaises performances - souvent, il est tout aussi facile et rapide d'écrire du code bon, robuste et efficace que d'écrire du courrier indésirable.

Mais vraiment, si la gestion des produits et le personnel d'AQ sont tous endormis au volant, nous les programmeurs ne pouvons pas compenser cela.

FWIW, je suis entièrement d'accord sur les interfaces abyssales de la plupart des produits de consommation. Cela fait maintenant environ 25 ans que j'écris du code d'interface utilisateur et je m'efforce d'élégance et de simplicité. C'est en fait un problème parce que j'y pense tellement, je suis maintenant moche à trouver des interfaces utilisateur mal conçues, donc ma pauvre femme finit par utiliser la plupart des appareils de notre centre multimédia.

Parce que les programmeurs ne sont pas parfaits.

Je suis programmeur de choses embarquées. Une partie de mon code n'est pas parfaite. La plupart de mon code intégré est rapide.

Résoudre les problèmes de performances à la fin d'un projet est très difficile.

Parfois, pour garder les choses simples (et donc testables, développables en temps réel, pas fatalement boguées), nous superposons des choses, comme l'entrée à distance à un "service" qui ne fait pas partie de l'application principale. Résultat final, latence. L'alternative est de tout mettre dans une application monolithique, c'est un buggy en C ou C ++ (les deux langages embarqués les plus courants.)

Parfois, votre appareil intégré dispose d'un planificateur de processus qui ne fait pas ce que vous voulez en tant qu'utilisateur. Très difficile à réparer en tant que développeur intégré.

La complexité provoque le retard, en raison de la latence sur la superposition. Vous avez demandé les fonctionnalités. Essayez un très vieux Nokia, comme le vieux 3210. Interface utilisateur rapide Zippy. Pas beaucoup de fonctionnalités.

Je soutiens que les développeurs ne deviennent pas plus intelligents, donc le matériel plus rapide est absorbé par les abstractions pour empêcher les fonctionnalités de s'entretuer. (Ou pas, dans le cas de votre iPhone)

Les performances de l'interface utilisateur doivent être une exigence que vous testez à mesure que la conception progresse.

S'il n'est pas spécifié, le développeur s'y habituera. Nous le faisons tous. "Mon bébé n'est pas moche"

Et ce ne sont pas les langues du GC; Java en temps réel intégré est si rapide qu'il fait peur. (Python intégré, d'autre part, est un chien total)

J'écris un programme qui lit les commutateurs sur les entrées numériques comme l'interface utilisateur. Il faut encore dé-rebondir le commutateur, donc le basculement très rapide du commutateur ne fonctionne pas, car le dé-rebond est de quelques couches. Idéalement, j'aurais une logique de rebond au bas de la pile du firmware, mais ce n'est pas ainsi que le matériel fonctionne.

Certains lecteurs DVD exécutent simplement un script "éjecter" pour effectuer l'éjection. Votre DVR a peut-être adopté cette approche pour maintenir les coûts de développement à un niveau raisonnable. Ensuite, vous lésinez sur le CPU ou la RAM et ça craint.

Est-ce parce que ceux-ci ont tous été écrits dans des langues gérées et récupérées plutôt que du code natif?

Non. Le code lent fonctionnera mal malgré tout. Bien sûr, une langue particulière peut introduire certaines classes de problèmes tout en en résolvant d'autres. Mais les bons programmeurs sont tout à fait capables de trouver des solutions de contournement avec suffisamment de temps.

Est-ce les programmeurs individuels qui ont écrit le logiciel pour ces appareils?

Partiellement. Dans de nombreux cas, il s'agit très probablement au moins d'un facteur contributif. Il s'agit d'un effet secondaire malheureux d'une industrie où les bons programmeurs sont en forte demande et en pénurie. De plus, les écarts entre les différents niveaux de capacité technique peuvent être assez importants. Il va donc de soi que parfois les programmeurs chargés d'implémenter certains logiciels peuvent être félicités simplement pour les faire fonctionner (en quelque sorte).

Dans tous ces cas, les développeurs d'applications savaient exactement quelle plate-forme matérielle ils visaient et quelles étaient ses capacités; n'en ont-ils pas tenu compte?

Partiellement. Pour commencer, la plate-forme matérielle exacte n'est probablement pas connue, car elle est souvent négociée en parallèle avec divers fabricants lors du développement de logiciels. En fait, il peut même y avoir de petites modifications (mais pas nécessairement insignifiantes) du matériel sous-jacent après la version initiale. Cependant, je conviens que les capacités générales seront connues.

Une partie du problème est que le logiciel n'est probablement pas développé sur le matériel, il se fait dans des émulateurs. Cela rend difficile la prise en compte des performances réelles de l'appareil même si les émulateurs sont précis à 100% - ce qu'ils ne sont pas.

Bien sûr, cela ne justifie pas vraiment des tests insuffisants sur le matériel prototype approprié avant sa sortie. Ce blâme se situe probablement en dehors du contrôle dev / qa.

Est-ce le type qui répète "l'optimisation est la racine de tout mal", les a-t-il égarés?

Non, je suis quasiment certain qu'ils ne l'écoutent pas de toute façon; sinon il ne serait pas mal cité si souvent (c'est censé être une " optimisation prématurée ..."). :-RÉ

Il est plus probable que trop de programmeurs adoptent l'un des deux extrêmes en ce qui concerne l'optimisation.

• Soit ils l'ignorent complètement.
• Ou ils s'obsèdent avec des détails qui n'ont rien à voir avec les exigences de performances réelles . L'effet net étant que le budget est épuisé et le code est trop brouillées pour optimiser les réel en toute sécurité les problèmes de performance.

Était-ce une mentalité de "oh c'est juste 100 ms supplémentaires" à chaque fois jusqu'à ce que toutes ces millisecondes ajoutent des minutes?

Peut-être. De toute évidence, s'il Sleep(100)a été utilisé comme équivalent de papier de soie utilisé pour ralentir le saignement d'un membre sectionné - des problèmes sont à prévoir. Cependant, je soupçonne que le problème est plus subtil que cela.

Le truc, c'est que le matériel informatique moderne (y compris les appareils embarqués) est beaucoup plus rapide que les gens ne le reconnaissent. La plupart des gens, même les programmeurs "expérimentés", ne savent pas à quel point les ordinateurs sont rapides. 100 ms, c'est long - très long . Et en l'occurrence, ce "très long temps" se divise en deux:

• La première est que les programmeurs s'inquiètent inutilement des choses qu'un ordinateur fait extrêmement rapidement. (Il se trouve que c'était juste une telle préoccupation " incrémenter une valeur 300 fois par seconde " qui m'a conduit ici en premier lieu.)
• La seconde est qu'ils ne parviennent pas toujours à faire preuve de préoccupation lorsque les choses prennent très longtemps (sur l'échelle de temps de calcul). Alors:
  • s'ils ignorent les effets de la latence lors de la communication sur un réseau ou avec un périphérique de stockage;
  • s'ils ignorent l'impact d'un thread bloqué et en attente d'un autre thread;
  • s'ils oublient que parce que les ordinateurs fonctionnent si rapidement, il est très capable de répéter une tâche beaucoup plus souvent qu'il ne le devrait, sans que le développeur soit au courant d'un problème
  • ... si une combinaison de ces oublis se produit, une routine s'exécutera de manière inattendue très lentement (sur l'échelle de temps de calcul). Quelques répétitions et cela sera même perceptible par les humains - mais il peut être difficile à cerner car des centaines de choses interconnectées fonctionnent toutes rapidement par elles-mêmes.

Est-ce ma faute, pour avoir acheté ces produits en premier lieu?

Oui définitivement. Eh bien, pas vous personnellement, mais les consommateurs en général. Les produits sont vendus (et achetés ) par des listes de contrôle des fonctionnalités. Trop peu de consommateurs exigent de meilleures performances.

Pour illustrer mon propos: La dernière fois que j'ai voulu acheter un téléphone portable, le magasin ne pouvait même pas proposer un modèle de démonstration pour jouer avec en magasin. Tout ce qu'ils avaient, c'était des coques en plastique avec des autocollants pour montrer à quoi ressemblerait l'écran. Vous ne pouvez même pas avoir une idée de ce poids - sans parler des performances ou de la convivialité. Mon point est que si suffisamment de personnes s'opposaient à ce modèle d'affaires et votaient avec leurs portefeuilles pour exprimer leur objection, nous ferions un petit pas dans la bonne direction.

Mais ils ne le font pas, donc nous ne le sommes pas; et chaque année, les nouveaux téléphones portables fonctionnent plus lentement sur un matériel plus rapide.

(Les questions non posées.)

• Les gens du marketing sont-ils à blâmer? Partiellement. Ils ont besoin de dates de sortie. Et lorsque cette date se profile, le choix entre «faire fonctionner» et «accélérer» est une évidence.
• Les vendeurs sont-ils à blâmer? Partiellement. Ils veulent plus de fonctionnalités dans la liste de contrôle. Ils accroissent les listes de fonctionnalités et ignorent les performances. Ils font (parfois) des promesses irréalistes.
• Les gestionnaires sont-ils à blâmer? Partiellement. Les gestionnaires inexpérimentés peuvent faire de nombreuses erreurs, mais même les gestionnaires très expérimentés peuvent (à juste titre) sacrifier du temps pour résoudre les problèmes de performance au profit d'autres préoccupations.
• Les spécifications sont-elles à blâmer? Partiellement. Si quelque chose n'est pas spécifié, il est beaucoup plus facile de "l'oublier" plus tard. Et si ce n'est pas spécifiquement indiqué, quel est l'objectif? (Bien que je pense personnellement que si une équipe est fière de son travail, elle se souciera de la performance malgré tout.)
• L'éducation est-elle à blâmer? Peut être. L'éducation sera probablement toujours en retrait. Je désapprouve certainement l '"éducation" qui produit rapidement des débutants avec un développement logiciel de compréhension superficielle. Cependant, une éducation qui s'appuie sur la théorie et inculque une culture d'apprentissage ne peut pas être mauvaise.
• Les mises à niveau sont-elles à blâmer? Partiellement. De nouveaux logiciels, de vieux matériels tentent vraiment le destin. Avant même la sortie de la version X, X + 1 est en cours de planification. Le nouveau logiciel est compatible, mais l'ancien matériel est-il assez rapide? At-il été testé? Un correctif de performance particulier peut être intégré dans le nouveau logiciel - encourageant une mise à niveau logicielle mal avisée.

Fondamentalement, je crois qu'il existe de nombreux facteurs contributifs. Donc, malheureusement, il n'y a pas de solution miracle pour y remédier. Mais cela ne signifie pas que c'est le destin et la tristesse. Il existe des moyens de contribuer à l'amélioration des choses.

Alors, à quel moment les choses ont-elles mal tourné pour ces produits?

À mon humble avis, nous ne pouvons pas vraiment identifier un seul point. Il existe de nombreux facteurs contributifs qui ont évolué au fil du temps.

• Compteurs de haricots: réduction des coûts, synchronisation du marché. Mais là encore, aurions-nous fait les progrès que nous avons réalisés sans la pression?
• Demande élevée et faible offre de personnes qualifiées dans l'industrie. Pas seulement des programmeurs, mais aussi des managers, des testeurs et même des commerciaux. Le manque de compétences et d'expérience conduit à des erreurs. Mais là encore, cela conduit également à l'apprentissage.
• Une technologie de pointe. Jusqu'à ce qu'une technologie arrive à maturité, elle mordra régulièrement de manière inattendue. Mais là encore, cela a souvent fourni un certain nombre d'avantages en premier lieu.
• Complication composée. Au fil du temps, l'industrie a évolué: en ajoutant plus d'outils, de technologies, de couches, de techniques, d'abstractions, de matériel, de langues, de variations, d'options. Cela rend quelque peu impossible d'avoir une compréhension "complète" des systèmes modernes. Cependant, nous sommes également capables de faire beaucoup plus dans un délai beaucoup plus court.

Que pouvons-nous faire en tant que programmeurs pour éviter d'infliger cette douleur à nos propres clients?

J'ai quelques suggestions (à la fois techniques et non techniques) qui peuvent vous aider:

• Dans la mesure du possible, utilisez votre propre produit. Rien de tel qu'une expérience de première main pour révéler des choses maladroites, lentes ou incommodes. Cependant, vous devrez éviter consciemment de contourner les carences dues aux "connaissances d'initiés". Par exemple, si vous n'avez aucun problème à synchroniser les contacts parce que vous le faites avec un script Python de porte dérobée - vous n'utilisez pas "le produit". Ce qui soulève le point suivant ...
• Écoutez vos utilisateurs (de préférence de première main, mais au moins de seconde main via le support). Je sais que les programmeurs préfèrent (généralement) rester cachés et éviter les interactions humaines; mais cela ne vous aide pas à découvrir les problèmes rencontrés par d'autres personnes lors de l'utilisation de votre produit. Par exemple, vous ne remarquerez peut-être pas que les options de menu sont lentes, car vous connaissez tous les raccourcis et les utilisez exclusivement. Même si le manuel documente entièrement tous les raccourcis, certaines personnes préfèreront toujours les menus - malgré leur insupportablement lent.
• Efforcez-vous d'améliorer vos compétences et connaissances techniques de façon continue. Développez les compétences nécessaires pour analyser de manière critique tout ce que vous apprenez. Réévaluez régulièrement vos connaissances. Dans certains cas, soyez prêt à oublier ce que vous pensiez savoir. Ce qui amène ...
• Certaines technologies / techniques peuvent être très délicates et conduire à des malentendus subtils et à des implémentations incorrectes. D'autres à travers l'évolution des connaissances communes ou des outils disponibles peuvent tomber en faveur ou par disgrâce (par exemple Singletons). Certains sujets sont si délicats qu'ils engendrent un tas de "pandits hocus-pocus" qui propagent un énorme corps de désinformation. Un bug particulier est le mien la désinformation entourant le multi-threading. Une bonne implémentation multi-thread peut améliorer considérablement l'expérience utilisateur. Malheureusement, beaucoup d'approches mal informées du multi-threading réduiront considérablement les performances, augmenteront les bugs erratiques, augmenteront les risques de blocage, compliqueront le débogage, etc.
• Prendre possession. (Non, sérieusement, je ne joue pas au bingo de la salle de conférence.) Négociez avec les gestionnaires, les propriétaires de produits et les vendeurs pour que les fonctionnalités de performance aient priorité sur certains éléments de la liste de contrôle. Exigez de meilleures spécifications. Pas enfantin, mais en posant des questions qui amènent les gens à réfléchir à la performance.
• Soyez un consommateur averti. Choisissez le téléphone qui a moins de fonctionnalités mais qui est plus rapide. (Pas un processeur plus rapide, une interface utilisateur plus rapide.) Alors vantez-vous ! Plus les consommateurs commencent à exiger des performances, plus les compteurs de haricots commenceront à les budgétiser.

Votre première erreur, et probablement la raison pour laquelle vous avez obtenu un vote négatif, mérite une exagération flagrante. Vous attendez-vous vraiment à croire que l'iPhone et l'iPad sont si mauvais?

En fin de compte, le client est responsable. Cela se résume au coût et à ce que le client est prêt à payer et à ce qu'il obtient en retour. S'ils choisissent les fonctionnalités plutôt que la vitesse, c'est ce qu'ils obtiennent. S'ils choisissent le prix plutôt que la vitesse, c'est ce qui est construit et vendu. Si l'image de marque est plus importante ... En fin de compte, le client décide avec son portefeuille, ce qui est important et ce qui ne l'est pas. Vous avez le choix d'être une putain de marque et d'acheter des produits parce que tout le monde le fait, ou être un penseur indépendant, regardez derrière le battage publicitaire et le battage publicitaire, et achetez quelque chose qui répond à vos besoins.

Vous blâmez les programmeurs. Ils ont écrit le code, bien sûr, mais ils n'ont pas défini, et ne devraient pas définir, les exigences des clients, le matériel, le coût de la nomenclature, le coût de la R&D, le budget marketing ..... tout ce qui va faire un produit , ce n'est pas un logiciel.

Les technologies utilisées, les langues utilisées, etc., n'ont rien à voir avec cela. Mauvais vs bons développeurs, rien à voir avec ça. Tout programmeur à moitié décent peut exécuter un morceau de code plus rapidement, être plus réactif, être le meilleur possible. D'après mon expérience, les programmeurs décents ne mettent pas l'entreprise en faillite lorsqu'ils doivent prendre les décisions, tandis que ceux à moitié décents se plaignent du "mieux" que cela devrait "être".

L'optimisation prématurée est parfois mauvaise, mais pas lorsqu'elle est nécessaire pour une bonne expérience utilisateur ou une bonne durée de vie de la batterie dans un système suffisamment contraint. L'échec est la faute de donner une priorité plus élevée au nettoyage de l'ingénierie logicielle maintenable par rapport à la cuisson dans tout ce qu'il faut pour offrir une bonne expérience utilisateur et une durée de vie décente de la batterie comme une priorité plus élevée au début d'un projet, même s'il est beaucoup plus difficile à entretenir et court circuits une pile logicielle et une méthodologie bien conçues.

Si vous avez un iPhone 3G, Apple a publié quelques mises à jour du système d'exploitation qui n'étaient optimisées que pour les appareils plus récents. Les mises à jour ultérieures du système d'exploitation pour la 3G peuvent offrir des performances légèrement meilleures sur la 3G.

Votre DVR prend autant de temps pour changer de chaîne car il doit d'abord vider les données en mémoire tampon, puis mettre en file d'attente une autre mémoire tampon pleine de données pour la nouvelle chaîne que vous regardez. Ce tampon est probablement stocké sur le disque dur, de sorte que ces opérations prennent du temps (en plus, il ne peut remplir le tampon qu'en temps réel). Avec un DVR, vous ne regardez jamais la programmation "en direct", elle est toujours retardée (pas par coïncidence, elle est retardée en même temps que votre retard perçu lors du changement de chaîne). Cela peut facilement être vérifié en regardant un programme sportif en même temps que vous l'écoutez à la radio.

Je pense que la raison en est que la plupart des applications destinées aux consommateurs sont contrôlées et commercialisées par des personnes qui ne connaissent rien aux logiciels, et embauchent des développeurs en fonction de leur curriculum vitae ou des recommandations d'un gestionnaire de rien, par opposition à leurs compétences et connaissances réelles .