tu peux aussi zipper la page (inflate or gzip) et tu n'auras plus besoin d'optimiser de cette facon :-)Envoyé par pmithrandir
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
tu peux aussi zipper la page (inflate or gzip) et tu n'auras plus besoin d'optimiser de cette facon :-)
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...
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.
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.
Des fois on peut optimiser, et gagner en lisibilité en même temps. Mais, le plus souvent, optimiser, c'est rajouter une finesse. Dans le code que j'a désoptimisé(en faisant sauter la bufferisation), si j'avais du garder la bufferisation, il me fallait rajouté 2 IF aux conditions assez exotiques. Donc rajouter du code. Plus il y a de code - même lisible - et moins c'est lisible. Sans compter - ce qui n'est pas précisé dans l'article - le risque de se gauffrer dans le code ajouté, et de laisser passer un bug rare(les pires, car difficile à detecter et à corriger).
Ben justement, dans l'exemple de la news, on ne parle pas d'optimisation de code mais d'espace disque. Et écrire le moins de caractères possibles pour gagner de la place nuit forcément à la lisibilité.
Moi je préfère accès sur l'optimisation des performances.
La limite est dès lors que ça devient ridicule en terme de gain/d'énergie/de lisibilité
Réponse pragmatique : 80/20.
Toujours partir d'un code non-optimisé mais clair, lisible, maintenable (sauf cas particuliers, voir ci-dessous).
Si pas de problèmes de performances, on en reste là.
Si problème de performances, on commence à regarder, quitte à aller jusqu'au 80/20 : optimiser les 20% de code qui s'exécute 80% du temps.
Après il y a bien sûr des exceptions : il y a certaines choses dont on voit bien dès le départ, en fonction des besoins, qu'il s'agira de code "sensible" qui gagnera à être dès le départ gaulé dans une optique d'avoir des bonnes performances.
Rappel : en effet, parfois "ré-optimiser après coup" peut être particulièrement couteux sur la conception initiale est mal adaptée.
Partie du code
Bonjour,
Aprés rien n'empèche d'optimiser que certaines partie du code. cela feras un bon compromis entre lisibilité et rapidité, il suffira de mieux/plus "commentariser" ces partie.
Je pense notamment au domaine du jeu vidéo 3D qui demande surement certaines optimisations de la part du développeur en plus des optimisations du compilateur.
Cordialement.
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.
La question est incomplète.... tout dépend du problème abordé. La question est de connaitre la criticité de la performance du problème, c'est tout.De quelle école êtes-vous ? Celle du code lisible ou au contraire, préférez-vous l'optimisation des performances ?
J ai appris a programmer sur des ordi qui avaient 100 fois moins de perf que le plus bete telephone sur le marche aujourd hui , alors j ai pris la "mauvaise" habitude de sur optimiser mon code. au point ou parfois quand je lit certain code bien "lisible" et bien "commente" je suis completement perdu et je mets des heures a comprendre pourquoi avoir ecrit ca ainsi ...
certes il est vrai qu aujourd hui nos ordi sont des betes de courses avec des memoires et des hd gigantesques . Mais imaginez vous que vous deviez ecrire un soft qui tournerai sur un pc datant de 10 ou 15 ans , cela donnerai quoi ?
je me souviens que sur un hd de 20 mega , j avait enormement de soft a mes debuts , pas des soft ridicules de jeux , je parle de suite a l office ou des soft d architecture . aujourd hui la puissance de nos pc conduit a une sorte de confort de travail du programmeur qui bien souvent si son soft est un peu lent se dira "bah dans 6 mois le pc qui sera la norme le fera tourner correctement alors je m en tape". Moi la ou je vit , je doit souvent faire des soft qui tournent sur de vieux p3 asthmatique voir des p2 , d ou des heures de galeres pour simplement faire que le chargement du soft n endorme pas son utilisateur. toutes cette debauche de puissance me semble bien plus utile dans un certain sens pour les jeux que pour les utilitaires ou une reelle optimisation du code algo etc peut faire de vrai miracle
C'est par ce genre de raisonnement qu'on a aujourd'hui des programmes qui font à peu près les même choses qu'il y'a 10 ans, mais qui prennent 100 fois plus d'espace disque, occupent 20 fois plus de mémoire et nécessitent des CPU de plus en plus puissants.
La course au besoin de puissance n'est pas une bonne chose. Certes, les coûts des machines diminuent, mais est-ce pour autant une raison de se précipiter dans le modèle de la société de sur-consommation? Pourquoi ne peut-on plus garder son PC plus d'1 an avant de le voir étouffer et sentir son disque dur partir dans une crise de spasmophilie dès qu'on lance un programme?
Il faut réussir à trouver un équilibre entre les deux.
Il ne faut pas perdre de vue non plus qu'on demande de plus en plus de chose à ces programmes. Ce qu'on demandais d'un traitement de texte il y a 10 ans n'est pas ce qu'on en demande aujourd'hui. Avec l'augementation des fonctionnalité et des exigences, forcément le code deviens plus gros. Maintenant, ca n'empeche pas d'optimiser, mais on dois le faire quand on a identifié les endroit ou c'était nécessaire. Systématiquement tout optimiser c'est arriver au résultat inverse de celui voulu.
je connais peu de gens qui utilisent plus de 5% des fonctionnalités de Word ou Excel
au jour le jour, non, mais ces 95% finiront par servir. Par expérience, certains fonctionnalités dans certains logiciels, c'est le genre de trucs que j'utilise une fois toutes les lunes. Mais quand j'en ai besoin, je suis content qu'elles soient là (comme la semaine passée, j'ai demandé à oocalc de me faire une régression linéaire et 2 3 trucs de stats)je connais peu de gens qui utilisent plus de 5% des fonctionnalités de Word ou Excel
et tu avais déjà tort...
Comme le dit SinDronX :
J'ai commencé avec des ordis 10 000 fois moins puissants que ceux d'aujourd'hui, et même il y a peu avec seulement 4 Go (ce qui était déjà gigantesque) d'HD.
C'est bizarre, mais mes codes (pourtant non "optimisés" à la brute) tournent toujours, et de plus en plus vite...tout en ne consommant quasi rien ... Et en faisant toujours ce pour quoi ils étaient conçus (et qui était complexe)...
Je ré-itère donc ma position : vouloir mette de l'assembleur, faire de l'obfuscation, tenter d'optimiser des instructions par un code illisible est une pratique non seulement suicidaire si c'est au sein d'une entreprise, mais également personnelle, et qui n'apporte strictement rien...
Un bon code optimisé est un code optimisé en usage mémoire et en algorithme.
Tout le reste est tellement dépendant des architectures qu'il faudra le refaire dès le prochain changement, et donc perdre en temps (et donc en argent, et donc en optimisation) ce qui avait été fait...
A quelques exceptions près.... extrêmement rares...
je suis assez d'accord, d'ailleurs la dernière fois que l'on ma demandé d'optimiser quelque chose, le code était relativement illisible et pas commenté.
Après analyse des algos et de ce qu'ils devaient faire on s'est rendu compte qu'il étaient inutilement complexe et qu'ils "bouibouitaient" inutilement.
bref après l'optimisation le code était moins complexe et obscure, plus lisible et correctement commenté et marchait beaucoup mieux.
Tu soulèves un paradoxe, dans la mesure où l'architecture fait partie de la conception d'un programme, au point où l'algorithme et la conception sont deux notions a part entière, pour ne pas dire complémentaires et du coup sont des critères à prendre individuellement en compte dans l'optimisation.
Même un langage de programmation peut entrer dans la notion d'optimisation si on parle de compilation native, managée ou dynamique.
Est ce que parler "d'optimisation du code" est la bonne expression, c'est une autre question.
Répondre avec citation
Partager