Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Ce que montre cet article, c'est surtout la capacité de certains à se perdre dans des considérations techniques assez accessoires et anecdotiques.
Et ça apparait surtout quand on commence à utiliser dans des projets des éléments ou des technos que l'on croit maitriser et qu'au final on ne maitrise pas tant que ça...
La définition mathématique est la meilleure:Envoyé par Paul TOTH
il faut optimiser son code.
Optimiser : Rendre optimal, donner à quelque chose les meilleures conditions d'utilisation, de fonctionnement, de rendement, notamment en économie.
ce qui ne veux pas dire que le programme sera pour autant plus rapide
C'est une autre façon de dire qu'on peut améliorer d'un point de vue qualitatif et quantitatif un code au sens "c'est mieux qu'avant" dans l'idée de l'économie d'énergie pour faire une action en cherchant le minimum( plutôt que le maximum) d'une fonction (la dérivée), en l'occurence dépendant de plusieurs variables (temps d'execution, lisibilité, etc ...).Raisonnement ou calcul permettant de trouver les valeurs d'un ou plusieurs paramètres qui correspondent au maximum d'une fonction`
En somme, il s'agit d'utiliser l'algorithme le plus performant par rapport à une situation donnée, voir d'une combinaison d'algorithmes, qui plus est bien écrit(s).
oui, il existe cette possibilité.
Mon exemple n'était que théorique en fait, pour montrer qu'avec quelques boucles, on arrive parfois, dans de rare cas il est vrai, a des économies de bande passante(ou de traitement) en échange d'une perte de lisibilité.
Pour la solution canvas, même si c'est HS pour la discussion... HTML 5 n'est pas encore utilisable professionnellement du moment que tout les clients IE ne sont pas sous IE9... on a bien 10 ans devant nous pour y arriver.
Le problème avec cette définition, c'est qu'il n'y a qu'un mathématicien pour y comprendre quelque chose.
Moi je préfère dire qu'optimiser, c'est faire mieux à consommation de ressource constante, ou faire la même chose en consommant moins de ressource.
Ca implique que l'optimisation ne peut intervenir que dans un deuxième temps, puisqu'il faut déjà avoir une première solution à améliorer avant de pouvoir "l'optimiser".
Ca montre aussi qu'en fait, la question n'est pas de savoir s'il faut optimiser ou rendre un code lisible. Si on entre dans la démarche d'optimisation, c'est que le résultat n'est pas satisfaisant. Et un code lisible qui donne un résultat non satisfaisant, ça ne sert à rien, donc bon pour la poubelle.
En fait, la question c'est plutôt faut-il écrire un code efficace, qui consomme peu de ressource à chaque exécution, ou faut-il écrire un code agréable pour le développeur ? Faut-il réduire les coûts d'exploitation (coûts récurrents tout au long de la vie du produit) ou réduire les coûts de développements (coût qu'on doit payer uniquement au moment du développement) ?
Faut-il privilégier le confort des utilisateurs, ou faut-il privilégier celui des développeurs ?
Maintenant si on veut se préoccuper des performances et de la consommation de ressource de l'appli, c'est avant tout un problème d'architecture et de conception. Il faut concevoir les choses dès le départ pour qu'elles puissent être performantes.
Une conception plus efficace qu'une autre n'a pas de raisons d'être moins lisible.
Les cas où on doit réellement optimiser un code jusqu'à le rendre illisible sont rarissimes.
Le plus souvent, lorsqu'on veut opposer les deux, c'est qu'on ne sait faire ni l'un ni l'autre...
+1
Avant de commencer une optimisation sur un système (appli/archi/...), il faut d'abord avoir une solution qui répond au besoin en terme de cas d'utilisation. Mais pas en terme de performance qui est objectif quantifiable à atteindre (occupation mémoire/capacité à monter en charge/transactions par secondes/...)
Pour moi optimisé n'est en aucun cas synonyme d'illisibilité. Un code correctement optimisé restera lisible si la personne qui le fait est suffisamment consciencieuse pour documenter/commenter/expliquer ses choix.
Au passage, j'ai aussi vu du code pas optimisé et totalement illisible aussi, en général quand il pose problème, on se fait un nœud au cerveau pour le comprendre et se rendre compte qu'au final ce code ne fait que brasser des octets inutilement et qu'il y'a une façon bien plus simple et efficace de faire la même chose.
+1,Maintenant si on veut se préoccuper des performances et de la consommation de ressource de l'appli, c'est avant tout un problème d'architecture et de conception. Il faut concevoir les choses dès le départ pour qu'elles puissent être performantes.
Une conception plus efficace qu'une autre n'a pas de raisons d'être moins lisible.
Les cas où on doit réellement optimiser un code jusqu'à le rendre illisible sont rarissimes.
bazar: http://www.improetcompagnie.com/publ...ctacles-6.html
BÉPO la disposition de clavier francophone, ergonomique et libre: http://bepo.fr/wiki/Accueil
Emacs Wiki: http://www.emacswiki.org/
En attente de ce que produira: http://www.pushmid.com
bonjour,
de quel optimisation vous parlez parcequ'on peut optimiser un code de plusieurs facon.
Cordialement,
Moufid Soufiane
Chef de Projet Nouvelle Technologie
tu as raison, les optimisations étant très lié au contexte, il y'a a peu près autant de façon d'optimiser que d'applications.
Mais en général cela commence souvent par une mise en place d'outils de mesure des performance de ton application selon des critères/un contexte ainsi que la mise en place d'un environnement qui te permettra de reproduire et comparer tes différents résultats de tests de performances.
personnellement je parlais d'optimisation dans le cadre général, les critères de performances d'un(e) système/application/archi à l'autre pouvant être vraiment très différents et très dépendant du projet/client(s).
Et je ne crois pas avoir lu, hormis peu être quelques exemples que les personnes peuvent tirer de leurs expériences que l'on soit rentré dans le détail d'un système/d'une application en particulier.
bazar: http://www.improetcompagnie.com/publ...ctacles-6.html
BÉPO la disposition de clavier francophone, ergonomique et libre: http://bepo.fr/wiki/Accueil
Emacs Wiki: http://www.emacswiki.org/
En attente de ce que produira: http://www.pushmid.com
Dans ce genre de débat on peut difficilement faire l'impasse sur cette citation de Donald Knuth:
En gros, commencer par écrire un code qui marche, et ne l'optimiser que s'il s'avère être un bottleneck pour les perfs...Premature optimization is the root of all evil
Pas de questions techniques par MP ! Le forum est là pour ça...
Tutoriels : Les nouveautés de C# 6 - Accès aux données avec Dapper - Extraction de données de pages web à l'aide de HTML Agility Pack - La sérialisation XML avec .NET (Aller plus loin) - Les markup extensions en WPF
il faudrait demander son avis à Google
Bonjour à tous,
Ma foi, je réponds comme l'ingénieur standard : çà dépend du besoin.
Mais une chose est sûre pour moi : on fait d'abord un code aussi lisible que possible, et après, une fois qu'il fonctionne bien, on commence à se poser la question de son optimisation.
Comme cela, il est possible de partir d'une base saine, de repérer facilement les zones importantes, d'utiliser les outils appropriés et d'optimiser réellement ce qui en vaut le coup. Avec quelques ligne de commentaires bien sentis pour décrire les bidouilles qui ne seraient pas compréhensibles du premier coup d'œil, alors oui, on peut optimiser en restant relativement lisible.
Ce genre d'approche conduira a de très gros problèmes en pratique :Mais une chose est sûre pour moi : on fait d'abord un code aussi lisible que possible, et après, une fois qu'il fonctionne bien, on commence à se poser la question de son optimisation.
- Je ne vais pas vous apprendre comment se passe un projet dans la vrai vie. Au départ, on a le temps d'imaginer tout ce qu'on veut. On a plein de bonnes résolutions pour faire un code parfait... Et puis plus les échéances approchent, et plus ça devient : "il faut livrer. Tout ce qui compte c'est que ça marche, peu importe comment". En d'autres termes, si le code est déjà pourri au départ, il le sera encore plus ensuite... Je trouve assez naïf de croire qu'on l'optimisera ensuite.
- Ensuite comme je l'ai déjà dit, les performances sont avant tout une question de conception et d'architecture. Or une fois que l'appli est suffisament avancée pour pouvoir dire que le code marche et se rendre compte que les performances sont catastrophiques... ben c'est trop tard pour refaire la conception et revoir l'architecture. On est obligé de se limiter à de la cosmétique. C'est à dire de petites optimisations par-ci par-là, de mettre des verrus à droite à gauche qui vont rendre le code illisible parce qu'on ne peut plus mettre oeuvre la véritable solution : refaire une conception plus adaptée aux problèmes de performances. Sans compter que si on doit tout changer pour optimiser, il faudra relancer une nouvelle campagne de tests... En pratique on fera tout pour faire semblant de ne pas voir que les perfs sont catastrophiques, et ce sont les utilisateurs qui en feront les frais...
- Les perfs c'est la même chose que n'importe quelle contrainte. Si on la prend en compte suffisamment tôt (c'est à dire dès le départ), ça ne coûte rien. Par contre, plus on tarde à l'intégrer au projet, et plus les coûts explosent.
- Enfin, lorsqu'on commence à dire "d'abord je fais un code qui marche, ensuite je l'optimise" on met le pied sur une pente glissante particulièrement dangereuse.
Ca commence par : "d'abord je fais un code qui marche, ensuite... oups je n'ai plus le temps". Ca continue par : "tant pis, j'ai un code qui marche". Puis "ça marche, donc c'est bon". Ce qui ne manquera de devenir : "Ca marche, les perfs on s'en fout". Et enfin : "Bon j'ai deux solutions possibles. Elles marchent toutes les deux, donc elles sont équivalentes, je peux choisir indifféremment l'une ou l'autre... donc celle où j'ai le moins de code à tapper. Ce qui sera presque à coup sûr la moins performante.
Pourtant pour avoir de la performance, il suffisait de choisir celle qui allait donner les meilleures perfs...
Je comprends pas trop ce raisonnement... une solution plus performante n'est pas nécessairement plus longue
Sinon, je comprends ton point de vue bien sûr, c'est clair que si tu peux écrire un code performant dès le départ, autant le faire. On va pas non plus écrire volontairement du code non performant
Ce que je disais concernait surtout les "micro-optimisations", celles qui vont te faire gagner 2 ou 3 cycles d'horloge par-ci par là. En général, ce type d'optimisation est facile à réaliser après coup, parce qu'elles n'impliquent que des modifications locales, sans toucher à la structure générale du code. Si tu commences à t'en préoccuper dès le début sans même savoir l'impact réel que ça aura sur le programme final, ça risque d'être du temps perdu, qui aurait été employé plus utilement à se concentrer sur l'essentiel (à savoir produire un code qui fonctionne correctement).
Bien sûr, les "grosses" optimisations, celles qui vont vraiment avoir un impact mesurable, ont en général une plus grande influence sur la structure globale du code, et donc il vaut mieux les prévoir dès le départ (dans la mesure du possible, vu qu'on ne peut malheureusement pas tout prévoir...)
Après, évidemment ça dépend aussi du type de code que tu écris... si c'est du code pour des systèmes embarqués avec des contraintes de temps réel, tu vas forcément attacher plus d'importances aux micro-optimisations que si tu écris une application de gestion.
Bref, je ne pense pas que Donald Knuth ait voulu dire "on s'en fout des perfs"
Je vous amène un cas curieux, pour changer.
En général, j'applique le principe suivant: Si l'application mange beaucoup de mémoire (genre 4G de ram), et qu'il faut 1 mois de boulot pour corriger tout ce qui cause ça, ca coutera au bas mot 5000€ en salaire. A coté de ça, ajouter une barette de 4G (à l'époque, ram serveur, etc) : un bon 1000€. Dans les deux cas, le résultat final est supposé le même (application fluide, plus de swapping). La logique voudrais de prendre la deuxième (moins chère plus rapide à mettre en place). Demande est faite. Réponse: "Non, on a pas le budget". Par contre le développeur, qu'il soit là dessus ou ailleur, on le paie quand même donc en fait, il ne coute rien de supplémentaire à budgetiser.... On aura juste un autre projet en retard
La logique et l'administration parfois
autre historie que j'avais vue. Trois mois de boulot, toute une équipe, et un présentation en grande pompe pour montrer les optimisation d'un logiciel serveur, optimisation par un gros guru qui ont couté 20.000$ en frais de personnel (pas chez nous hein, une belle sur thedailywtf pour ce qui connaissent). Au bout de la présentation: "Si j'ai bien compris, vous avez dépensé 20.000$ de temps pour résoudre en trois mois un problème que vous auriez pu résoudre en achetant pour 250$ de matériel et avec seulement deux jours?"
Je modulerais cette réponse. Pour moi, il faut toujours faire tourner le programme avant de décider d'ou on optimise. Seule une utilisation réelle du programme permettra d'identifier les points chauds. Par expérience sur les quelques fois ou j'ai du le faire. Ce n'est JAMAIS là ou tu pensais que c'était pendant l'analyse. C'est souvent un truc auquel t'as pas pensé qui t bouffe 90% de tes cycles et tu te dis à ce moment là "si j'avais sur optimisé là ou je pensais que c'était nécessaire, que de temps j'aurais perdu pour rien". Alors oui, si tu sais écrire une procédure, un bloc, rapide du premier coup, fait le. Si t'as le choix entre une implémentation pas performante en 20 minutes et l'implémentation performante en 2 jour, laisse tomber l'optimisation, tu te grattera la tête quand ce sera nécessaire, si c'est nécessaire.
je ne suis pas du tout d'accord avec ton approche. Avec cette logique, tu peux acheter un serveur par application, tu multiplies les serveur...à ben non tu virtualises, mais tu te retrouves avec une ferme de serveurs virtualisés, avec les licences qui vont avec...tout cela parce que le développeur a dit, il suffit d'ajouter de la RAM, ça coûte moins cher que mes neurones. D'autant que la dépense est répercutée chez chaque client, alors que tes neurones on ne les paye qu'une fois, et si tu travailles intelligemment, ton code est réutilisable, alors que la RAM utilisée par ta première appli n'est pas disponible pour la suivante.Je vous amène un cas curieux, pour changer.
En général, j'applique le principe suivant: Si l'application mange beaucoup de mémoire (genre 4G de ram), et qu'il faut 1 mois de boulot pour corriger tout ce qui cause ça, ca coutera au bas mot 5000€ en salaire. A coté de ça, ajouter une barette de 4G (à l'époque, ram serveur, etc) : un bon 1000€. Dans les deux cas, le résultat final est supposé le même (application fluide, plus de swapping). La logique voudrais de prendre la deuxième (moins chère plus rapide à mettre en place). Demande est faite. Réponse: "Non, on a pas le budget". Par contre le développeur, qu'il soit là dessus ou ailleur, on le paie quand même donc en fait, il ne coute rien de supplémentaire à budgetiser.... On aura juste un autre projet en retard
La logique et l'administration parfois
autre historie que j'avais vue. Trois mois de boulot, toute une équipe, et un présentation en grande pompe pour montrer les optimisation d'un logiciel serveur, optimisation par un gros guru qui ont couté 20.000$ en frais de personnel (pas chez nous hein, une belle sur thedailywtf pour ce qui connaissent). Au bout de la présentation: "Si j'ai bien compris, vous avez dépensé 20.000$ de temps pour résoudre en trois mois un problème que vous auriez pu résoudre en achetant pour 250$ de matériel et avec seulement deux jours?"
je m'insurge donc contre cette théorie qui voudrait qu'il suffit de mettre du hardware pas cher pour combler les lacunes de développement. Développeurs qu'on peut alors payer au lance-pierre puisque le hard serait là pour rendre le produit utilisable.
J'entends le même discours sur le développement spécifique, on va pas s'emmerder à payer un développeur très cher pour faire un produit sur mesure alors qu'on peut faire rentrer nos besoins dans un produit générique. Le problème c'est que ce discours vient souvent de la direction avec une logique budgétaire et rarement de l'utilisateur final avec une logique de travail !
S'il faut trois mois de plus pour avoir un produit efficace, c'est le développeur qu'il faut changer, pas l'approche.
En même temps, tout ça c'est souvent des erreurs de conception à la base.
C'est le cas du dba qui un jour avait remonté les 400 pages de listing SQL que produisait une appli J2EE avec du hibernate; ceux qui ont massivement utilisé de l'AOP 'soft' et des proxys qui se rendent compte que le proxy a un coup, où la surconsommation du singleton. Le sur-emploi de patterns inutiles, de frameworks...Il y a des technologies plus propices que d'autres en outre à produire du bloated development.
Maintenant démarrer un développement sans se poser la question des performances attendues, sans profiler et sans vraie politique qualité, c'est une économie à court terme qui est une bombe économique à moyen terme.
Quelle que soit l'activité, la marge dans le développement c'est l'absence de maintenance. Quand tu passes 150j à faire un truc facturé 200j; il te reste 50j de marges dont le seul critére de viabilité et que le livrable ne nécessite pas plus de 50j de maintenance 'gracieuse'.
Hors pour faire de la marge, aujourd'hui on sacrifie la qualité, parce qu'au fond avec la politique du larbin qu'accepte les gens aujourd'hui, ils finiront toujours dans le temps à faire marchouiller une application mal pensée mais qui n'a pas couté cher, puisque réalisée en maintenance. C'est le satisfecit de la médiocrité.
Moi la logique, elle est claire. J'ai des besoins utilisateur à satisfaire, j'ai trois personnes dans mon équipe, et je dois gérer ces ressource. Alors oui, si rajouter 4G dans un serveur, qui est chez nous (c'est du dev interne, il n'y a aucune distribution ou répercussion chez des clients potentiel) permet de résoudre le problème et me permet d'avoir un autre besoin supplémentaire satisfait au final, car mon équipe s'est pas cassé la tête à faire un gros refactoring pour contourner une limitation du serveur de prod, je n'hésite pas une seconde. J'ai jamais dit qu'il fallait écrire un code cochon non plus. Mais quand le problème est là et du simplement à un choix que l'équipe avait pris au départ de privilégier la clareté du code et la rapidité d'exécution au détriment de la mémoire dans le choix des algos, ca m'énerve quand on viens me dire après "on a pas ton serveur, on en a juste un tout petit au rabais, faut que ça rentre dedans".
Qui a dit que c'était une lacune de développement. Je vais te demander un traitement de texte complet à développer puis je vais te donner une machine avec 2M de ram pour le faire tourner, tu va encore parler de lacune quand on demandera une barette de minimum 512M? Dans mon cas c'était la même chose. Il faut être réaliste, faut tenir compte des coûts de chaque option, l'argent ne tombe pas du ciel. Oui on peut sortir son assembleur, ca calculette pour mesurer chaque octet prix et mettre 10 fois plus de temps pour développer un petit traitement de texte qui tiendra sur l'espace d'un carte sim. La question est toujours la même: ca vaut le coût?
même avec du hardware, tu ne compensera jamais un mauvais code. Un truc qui ne scale pas, même en triplant le hardware, il ne scalera toujours pas. De plus, ca ne rendra pas l'applicaiton sécurisée, ni stable, ni maintenable. Jamais je n'ai dit qu'il fallait travailler comme des cochons non plus. Je parlais bien de cas, courant cependant, ou tu dois faire le choix entre passer du temps à compresser et calculer chaque donnée que tu met en mémoire pour limiter ton empreinte, ou augmenter la mémoire et pouvoir dépenser ton énergie sur d'autres points importants du produit. N'oublie pas que le problème de départ n'est pas (dans mon cas) "l'application a besoin de trop de mémoire" mais "l'application est lente". La mémoire supplémentaire resolvais ce problème puisque la lenteur etait dûe au swap. Le code derrière était loin d'être mal fait, c'est juste qu'on demandais trop de chose à l'application pour les ressources dont elle disposait, donc on a du s'atteler à gaspiller du temps pour limiter ses besoisn, alors que le problème était clairement le calibrage des serveurs. D'ailleurs le problème est revenu 1 an plus tard sous une autre forme et toujours avec la même conclusion "on a pas assez de mémoire là"Développeurs qu'on peut alors payer au lance-pierre puisque le hard serait là pour rendre le produit utilisable.
Pour ce genre de discours, ca s'analyse au cas par cas, moi je vais te donner le problème inverse. Je vois souvent des devs qui veulent passer 4 mois à faire un développement spécifique en interne pour un besoin interne, tout ça parce qu'une virgule est mal placée sur une interface du produit existant. C'est tout aussi injustifiable qu'une administration qui veux te payer un tournevis parce que c'est moins cher qu'une clé anglaise (et je serre comment mon écrou avec le tournevis moi?) Il y a des extrêmes de chaque coté.J'entends le même discours sur le développement spécifique, on va pas s'emmerder à payer un développeur très cher pour faire un produit sur mesure alors qu'on peut faire rentrer nos besoins dans un produit générique.
Pour chaque produits, chaque problème, c'est toujours la même chose, il faut faire la balance entre les cout de chaque solution par rapport au gain utilisateur.Encore une fois, tout dépend. Je vais te donner un example. On nous a demandé d'interagir avec une application commerciale X que nous avions achetée. Le but: éviter aux utilisateur de devoir restranscrire des informations d'une applicaiton interne vers l'application commercial.ce discours vient souvent de la direction avec une logique budgétaire et rarement de l'utilisateur final avec une logique de travail !
Gain estimé:
-> confort important pour l'utilisateur
-> temps: 2 à 3 minutes / homme par jour (4 formulaire / jour à transcrire par copier/coller)
Cout estimé:
-> 1 semaine / homme de travail
-> 4000€ de licence+consultance obligatoire pour l'interaction
Total gain sur 1 ans
10*250/60 = 42h soit un peu plus d'une semaine de travail
Total coût
L'équivalent d'un mois de salaire
Assez bizzarement, j'ai du mal à justifier cet investissement auprès de ma direction.
Qui a dit que le produit de départ n'est pas efficace? Il y avait juste inadéquation entre le produit et les ressource qui lui étaient destinées. Et ça, en entreprise, c'est malheureusement très courant. Tu a un projet à mener à bien, tu détermine l'ensemble des tes besoin, client, et tu fais la somme des moyen, genre:S'il faut trois mois de plus pour avoir un produit efficace, c'est le développeur qu'il faut changer, pas l'approche.
pour l'appli machin, me faudra:
1 ldap, une base de donnée avec ~10G de stockage, 2 core sur le CPU, 1G de ram pour faire les traitement statistiques demandés, une connection 1Gbit pour faire l'acquisition des sources de données à vitesses raisonnable. On te budgetise le serveur. Tu fait ton dév. Fast forward 6 mois plus tard. On est plus la même année civile. Il y a eu des restriction budgétaire. Ton projet est fini et on te montre ta "machine", c'est un espace de stockage de 4G, sur une machine quad core dont les ressources CPU sont déjà utilisées à 80%, avec une connection 1gbit, certes, mais dont les 3/4 sont déjàs bouffés par un autre service. Il reste 800M d'espace en RAM avant de commencer à Swapper.
Puis après ce serait de la fautes aux devs?
bein n'oublie pas les couts cachées si des erreurs sont commises,
et voit cela sur plusieurs années...
tout à fait d'accord, mais ils avaient déjà été pris en compte
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager