Et comment vous déterminez que ça va plus vite ?

Benchmark ? Instrumentation de code ?
Enfin faut avouer que c'est pas souvent ce qu'on utilise...
On a des contraintes de temps de fonctionnement, donc on code et on l'exécute pour vérifier que c'est fonctionnel.
Si l'on rentre pas dans les spécs on recode jusqu'à trouver une solution qui correspond.
Et des fois personne n'arrive à mieux que le plat de spaghettis pour arriver à nos fins.

Mais c'est pas le plat de spaghetti qui doit faire peur, s'il a été étudié dans les moindres recoins et qu'il est audité comme clean on ne devrait pas avoir à revenir dessus.
Mais on est d'accord que quand le client veut une amélioration d'une fonction qui touche à un plat de spaghetti ça fait souvent mal...
Mais bon... Des fois il faut choisir entre la sécurité du pauvre militaire tout seul à l'autre bout du monde et notre sécurité mentale (et pis on a une bonne mutuelle, vous croyez qu'ils avaient prévu le coup ? ).

Donc, si je résume, vous passez tout votre temps à optimiser à l'aveugle plutôt que de faire une solution fonctionnelle, lancer des benchmarks et optimiser les points critiques ? (et au passage l'assertion qu'un code ne sera jamais modifié)

Donc, si je résume, vous passez tout votre temps à optimiser à l'aveugle plutôt que de faire une solution fonctionnelle, lancer des benchmarks et optimiser les points critiques ? (et au passage l'assertion qu'un code ne sera jamais modifié)

Sachant que cela coûte beaucoup moins cher pour la plupart des applications (particulièrement pour du web) de mettre une machine deux fois plus puissante plutôt que de payer l'équivalent d'H.M pour optimiser l'application... Et qu'en cas de départ de la personne qui a développé l'application initiale cela coûtera beaucoup plus cher que la personne déchiffre un code optimisé mal fait qu'un code non optimisé bien organisé...

Dans l'immense majorité des cas, le plus important est la conception du code, ensuite vient l'optimisation si cela ne gène pas le premier point.

Cordialement.

Donc, si je résume, vous passez tout votre temps à optimiser à l'aveugle plutôt que de faire une solution fonctionnelle, lancer des benchmarks et optimiser les points critiques ? (et au passage l'assertion qu'un code ne sera jamais modifié)

24h/24 sur des optimisations ? Mais qui serait assez fou pour faire un job comme ça ?
Tu extrapoles un peu vite, j'ai seulement dit que la majorité des cas nous n'avons pas besoin de benchmarks pour savoir qu'il faut faire quelque chose.
Et pour cause, quand une radio ne communique plus avec une autre c'est qu'on a un traitement qui prend trop de temps.
Dans la majorité des cas cela touche le protocole radio et donc on trouve la séquence qui va pas bien avec un peu d'expérience sur le produit et un oscilloscope.
Autant dire que c'est plus contraignant de mettre en place tout une batteries de tests, de benchs et j'en passe (et ce sans casser le temps réel siouplait !) que de faire cette simple mesure après modification à l'oscilloscope.

Et quand au domaine du web, c'est pas ma spécialité vu que je ne suis ici qu'en tant qu'amateur, mais je pense comme le dit Sékiltoyai que vu les performances que cela demande il est toujours moins coûteux pour 95% des types d'applications de passer à une architecture matérielle au dessus que de payer pour étudier et optimiser du code.

Et puis une bonne conception réduit le besoin d'optimisation.
Si on demande une 4L et qu'on veut l'utiliser comme une fusée bah... C'est un souci de conception, pas d'optimisation.

Donc, si je résume, vous passez tout votre temps à optimiser à l'aveugle plutôt que de faire une solution fonctionnelle, lancer des benchmarks et optimiser les points critiques ? (et au passage l'assertion qu'un code ne sera jamais modifié)

Sachant que cela coûte beaucoup moins cher pour la plupart des applications (particulièrement pour du web) de mettre une machine deux fois plus puissante plutôt que de payer l'équivalent d'H.M pour optimiser l'application... Et qu'en cas de départ de la personne qui a développé l'application initiale cela coûtera beaucoup plus cher que la personne déchiffre un code optimisé mal fait qu'un code non optimisé bien organisé...

Le postulat qu'un code optimisé est in-maintenable est purement et simplement fausse, quand c'est pas assez performant doublez la puissance de la machine, est ce que tu as fumé? y'a pas assez de ram doublez la ram, pas assez de procco rajoutez le dernier biproc 8 procco hyperthreadé qui va bien, je l'entend tous les jours celle la, franchement quand on est un informaticien qui se respecte on ne pense pas comme ça...

Dans l'immense majorité des cas, le plus important est la conception du code, ensuite vient l'optimisation si cela ne gène pas le premier point.
Cordialement.

Non, l'optimisation est partie intégrante de la conception, si tu ne penses pas le truc correctement à un niveau global tu ne le feras pas à un niveau particulier.

Donc, si je résume, vous passez tout votre temps à optimiser à l'aveugle plutôt que de faire une solution fonctionnelle, lancer des benchmarks et optimiser les points critiques ? (et au passage l'assertion qu'un code ne sera jamais modifié)

Sachant que cela coûte beaucoup moins cher pour la plupart des applications (particulièrement pour du web) de mettre une machine deux fois plus puissante plutôt que de payer l'équivalent d'H.M pour optimiser l'application... Et qu'en cas de départ de la personne qui a développé l'application initiale cela coûtera beaucoup plus cher que la personne déchiffre un code optimisé mal fait qu'un code non optimisé bien organisé...

Le postulat qu'un code optimisé est in-maintenable est purement et simplement fausse, quand c'est pas assez performant doublez la puissance de la machine, est ce que tu as fumé? y'a pas assez de ram doublez la ram, pas assez de procco rajoutez le dernier biproc 8 procco hyperthreadé qui va bien, je l'entend tous les jours celle la, franchement quand on est un informaticien qui se respecte on ne pense pas comme ça...

Quand on parle d'optimisation, on ne parle pas de quelques minutes pour doubler les performances, on parle de plusieurs hommes*jours pour gagner 10%, ce qui est en général énorme vu le coût. On ne dit pas que le code optimisé est nécessairement inmaintenable. Mais dans les cas où l'on sacrifie de la maintenabilité (donc du temps lors des interventions futures, voire le risque de voir apparaître de nouveaux bugs) pour un peu plus de performances, ce n'est pas forcément une bonne idée. A noter que les cas où cela arrive sont légions (par exemple remplacer une fonction générique par une fonction custom qui fera l'opération plus vite mais totalement dédiée au besoin actuel, etc).

Dans l'immense majorité des cas, le plus important est la conception du code, ensuite vient l'optimisation si cela ne gène pas le premier point.
Cordialement.

Non, l'optimisation est partie intégrante de la conception, si tu ne penses pas le truc correctement à un niveau global tu ne le feras pas à un niveau particulier.

Ce n'est pas parce que tu as une bonne conception que ton code est automagiquement optimisé. Par exemple si sur un gros projet tu organises ton codes par modules pour isoler les différentes tâches mais qu'ensuite tu dois découvrir, charger les modules, les faire communiquer, etc, tu peux facilement arriver à un code bien conçu mais un peu moins performant (on parle réellement de 10% là) que s'il était monolithique.
Enfin, de toute façon on ne peut pas dire qu'une conception est "bonne", c'est une notion hautement subjective...

Le postulat qu'un code optimisé est in-maintenable est purement et simplement fausse, quand c'est pas assez performant doublez la puissance de la machine, est ce que tu as fumé? y'a pas assez de ram doublez la ram, pas assez de procco rajoutez le dernier biproc 8 procco hyperthreadé qui va bien, je l'entend tous les jours celle la, franchement quand on est un informaticien qui se respecte on ne pense pas comme ça...

Quand on parle d'optimisation, on ne parle pas de quelques minutes pour doubler les performances, on parle de plusieurs hommes*jours pour gagner 10%, ce qui est en général énorme vu le coût. On ne dit pas que le code optimisé est nécessairement inmaintenable. Mais dans les cas où l'on sacrifie de la maintenabilité (donc du temps lors des interventions futures, voire le risque de voir apparaître de nouveaux bugs) pour un peu plus de performances, ce n'est pas forcément une bonne idée. A noter que les cas où cela arrive sont légions (par exemple remplacer une fonction générique par une fonction custom qui fera l'opération plus vite mais totalement dédiée au besoin actuel, etc).

Dans l'immense majorité des cas, le plus important est la conception du code, ensuite vient l'optimisation si cela ne gène pas le premier point.
Cordialement.

Non, l'optimisation est partie intégrante de la conception, si tu ne penses pas le truc correctement à un niveau global tu ne le feras pas à un niveau particulier.

Ce n'est pas parce que tu as une bonne conception que ton code est automagiquement optimisé. Par exemple si sur un gros projet tu organises ton codes par modules pour isoler les différentes tâches mais qu'ensuite tu dois découvrir, charger les modules, les faire communiquer, etc, tu peux facilement arriver à un code bien conçu mais un peu moins performant (on parle réellement de 10% là) que s'il était monolithique.
Enfin, de toute façon on ne peut pas dire qu'une conception est "bonne", c'est une notion hautement subjective...

Je ne comprend pas comment tu peux affirmer des choses aussi drastiques, oui c'est possible de faire de la performance dès le départ sans perdre aucun temps en refactoring derrière et sans perdre la maintenabilité, tel que tu décris tu vois de l'optimisation faite dans un code serveur en C, moi je te parle des technos dont on traite sur ce forum à savoir php javascript etc, quand à avoir besoin de plusieurs développeurs pendant plusieurs jours, il n'y a presque aucun projet qui nécessite ça, pour avoir fait de très gros projet (ex ce que je fais actuellement se compare à facebook en terme de taille de code et est sans doute plus complexe) absolument seul je suis bien placé pour le savoir.

Je ne comprend pas comment tu peux affirmer des choses aussi drastiques, oui c'est possible de faire de la performance dès le départ sans perdre aucun temps en refactoring derrière et sans perdre la maintenabilité, tel que tu décris tu vois de l'optimisation faite dans un code serveur en C, moi je te parle des technos dont on traite sur ce forum à savoir php javascript etc, quand à avoir besoin de plusieurs développeurs pendant plusieurs jours, il n'y a presque aucun projet qui nécessite ça, pour avoir fait de très gros projet (ex ce que je fais actuellement se compare à facebook en terme de taille de code et est sans doute plus complexe) absolument seul je suis bien placé pour le savoir.

Et moi je ne comprends pas comment tu peux généraliser à partir de ton expérience personnel sur un projet, sachant qu'en plus tu étais seul donc que tu n'avais ni recul ni regard objectif.

L'optimisation c'est subjectif et lié au besoin à partir de la tous est possible.

Je bosse sur une appli plutôt stable codée il y a 11 ans pour du php5 a la mode php 3.
Résultat : plats de spaghetti pour tout un village (des pages de + de 9k lignes procédurale sans fonction rien.
Audit de code : du "jamais vu" 100% de code dupliqué, 0% de respect des standards de codage.

Il m'arrive de passe 2 jours a trouver d'où vient un problèmes ou comment est faite une fonctionnalité a modifier pour parfois 1h de dev grand Max ....

Mais maigres le mendier et les requêtes sql dans le traitement d'une requête qui est dans le traitement d'une requête (pas de requête préparée côté serveur hein) l'appli est relativement performante.

Et cela couterait clairement plus chère de l'optimiser que de faire de la maintenance.

Ensuite être seul sur un gros projet c'est pas forcément un gros problème ce qui l'ai c'est le jour où il y a un problème et que le des n'est pas la. Si le code est merdique et qu'il n'y a pas de doc c'est la galère assurée.

Et côté techno j'ai vue des appli java aussi mal codée et plus lente pour moins de code.
Et les machines ne change la grande chose.

Pour finir je dirais qu'une grosse machinerie bien modélisée avec 28 couches sera forcément plus lente qu'un code qui vas direct faire ce que l'on veux vu qu'il y aura des classes à instancier parfois beaucoup) des requêtes sql générées par un orm qui va sûrement faire quelque chose de moins performant qu'un dba qui va te pondre une requête de complète etc etc.
Mais cela ne veux pas dire que ce code ne sera pas optimisé, ni qu’un code optimisé sera inmaintenable, s'il clair des le départ que tu n'as pas 2000 lignes pour afficher un tableau html


@+

Je résume : un code bien modélisé est forcément plus lent, c'est ça ? Est-ce que c'est un raccourcit trop important de dire que pour aller plus vite il faut des getters et des setters ?

Je résume : un code bien modélisé est forcément plus lent, c'est ça ? Est-ce que c'est un raccourcit trop important de dire que pour aller plus vite il faut des getters et des setters ?

Sur de grosses architectures oui.
Plus tu rajoutes de couche plus tu rajoutes du code difficile à conditionner, et donc au final tu exécutes du code qui n'a pas grande utilité.
C'est comme faire un Paris Nantes par l'autoroute, avec les couches cela implique de s'arrêter à chaque aire de repos que tu croises (avec nombre d'aire = nombre de couche). Et là je pense on est tous d'accord sur le fait que le trajet est plus long...

On a le même souci en embarqué quand on veut du code portable sur plusieurs hardware.
On doit se trimbaler des couches basses logicielles au lieu d'attaquer directement le hard.
C'est forcement un poil plus lent...

Je ne comprend pas comment tu peux affirmer des choses aussi drastiques, oui c'est possible de faire de la performance dès le départ sans perdre aucun temps en refactoring derrière et sans perdre la maintenabilité, tel que tu décris tu vois de l'optimisation faite dans un code serveur en C, moi je te parle des technos dont on traite sur ce forum à savoir php javascript etc, quand à avoir besoin de plusieurs développeurs pendant plusieurs jours, il n'y a presque aucun projet qui nécessite ça, pour avoir fait de très gros projet (ex ce que je fais actuellement se compare à facebook en terme de taille de code et est sans doute plus complexe) absolument seul je suis bien placé pour le savoir.

Et moi je ne comprends pas comment tu peux généraliser à partir de ton expérience personnel sur un projet, sachant qu'en plus tu étais seul donc que tu n'avais ni recul ni regard objectif.

Moi je crois que tu as confondu le début de ce que j'ai dit avec la fin surtout.

Je résume : un code bien modélisé est forcément plus lent, c'est ça ? Est-ce que c'est un raccourcit trop important de dire que pour aller plus vite il faut des getters et des setters ?

Sur de grosses architectures oui.
Plus tu rajoutes de couche plus tu rajoutes du code difficile à conditionner, et donc au final tu exécutes du code qui n'a pas grande utilité.

Si tu as un paquet de conditions, ce qui implique que ton système est pas conçu, donc ça ne colle pas avec mon propos.
Et puis même, ça impliquerait que chaque instruction dure le même nombre de cycles, ce qui est juste erroné.

C'est comme faire un Paris Nantes par l'autoroute, avec les couches cela implique de s'arrêter à chaque aire de repos que tu croises (avec nombre d'aire = nombre de couche). Et là je pense on est tous d'accord sur le fait que le trajet est plus long...

Je ne saisis pas l'analogie et puis comme je le disais, plus court != plus rapide.

On a le même souci en embarqué quand on veut du code portable sur plusieurs hardware.
On doit se trimbaler des couches basses logicielles au lieu d'attaquer directement le hard.
C'est forcement un poil plus lent...

c'est relatif, la plupart du temps les compilateurs font mieux que toi en pure asm.

Je ne comprend pas comment tu peux affirmer des choses aussi drastiques, oui c'est possible de faire de la performance dès le départ sans perdre aucun temps en refactoring derrière et sans perdre la maintenabilité, tel que tu décris tu vois de l'optimisation faite dans un code serveur en C, moi je te parle des technos dont on traite sur ce forum à savoir php javascript etc, quand à avoir besoin de plusieurs développeurs pendant plusieurs jours, il n'y a presque aucun projet qui nécessite ça, pour avoir fait de très gros projet (ex ce que je fais actuellement se compare à facebook en terme de taille de code et est sans doute plus complexe) absolument seul je suis bien placé pour le savoir.

Et moi je ne comprends pas comment tu peux généraliser à partir de ton expérience personnel sur un projet, sachant qu'en plus tu étais seul donc que tu n'avais ni recul ni regard objectif.

Moi je crois que tu as confondu le début de ce que j'ai dit avec la fin surtout.

Non.

c'est relatif, la plupart du temps les compilateurs font mieux que toi en pure asm.

Rien que de par cette phrase on voit que tu ne cernes pas ce que l'on cible par couche...
Portabilité et optimisation compilateur font bande à part.

Prenons un exemple bénin et dénué d'intérêt. Un handler de mémoire.
Cette couche va exécuter des algorithmes pour te trouver une zone mémoire, te la réserver, vérifier que ce que tu veux y stocker ne dépasse pas, ect.
Toi en tant que bon développeur tu vas vérifier que tu n'y stockes pas n'importe quoi (pointeur dont le contenu grossi en permanence ?).
Nous avons donc deux conditions qui font la même chose pour la protection de dépassement.
Trouves moi un seul compilateur qui optimise cela et je mange mon chapeau.

N.B : passons le fait que l'exemple est un peu stupide, vu que si on sait le handler bien fait on ne ferra pas de vérification de ce qu'on l'y stocke mais seulement gérer les erreurs retournées.