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
Discussion :
Après, bien sûr, si le problème est que les algorithmes sont impossibles à faire tourner sur une vieille machine quelle que soit l'implémentation (on pouvait faire du Ray Tracing sur Atari ST... mais 282 heures de calcul pour une seule image en très haute qualité, fallait avoir le temps), hé bien là il faut changer de machine.
à condition que ce soit faisable...Envoyé par I_believe_in_code
Or, jabbounet pointe justement du doigt le fait que ce n'est pas toujours possible au travers de sa situation propre, mais qui peut, aussi, simplement être le fait que beaucoup de gens n'ont qu'un budget qui leur permet tout juste de terminer le mois sans un sous
L'adaptation peut donc consister d'avantage à définir clairement ce qui est impensable avec la machine dont on dispose qu'à décider de changer de machine
[EDIT]Mais nous partons là vers un débat tout autre, qui n'a rien à voir avec la conception que l'on peut avoir d'un code propre
A méditer: La solution la plus simple est toujours la moins compliquée
Meme pour mes demos en GFA j'utilisais les bouclesJe me demande si le problème ne se situe pas ailleurs que là où tu le vois. A l'époque où les microprocesseurs tournaient à 8Mhz, les programmeurs ne s'amusaient pas (plus ?) à dérouler les boucles sous prétexte qu'ils avaient besoin de performance. (Sauf exceptionnellement, par exemple quand quelqu'un voulait programmer une démo ultra rapide sur un Atari ST avec un langage qui n'était pas prévu pour cela comme le GFA BASIC)
).
Mais cette époque est révolue. Avec la mémoire cache des processeurs, il est plus intéressant d'écrire une boucle compacte que de copier/coller des dizaines de lignes à la suite.
ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.
à condition que ce soit faisable...
Or, jabbounet pointe justement du doigt le fait que ce n'est pas toujours possible au travers de sa situation propre, mais qui peut, aussi, simplement être le fait que beaucoup de gens n'ont qu'un budget qui leur permet tout juste de terminer le mois sans un sous
L'adaptation peut donc consister d'avantage à définir clairement ce qui est impensable avec la machine dont on dispose qu'à décider de changer de machine
[EDIT]Mais nous partons là vers un débat tout autre, qui n'a rien à voir avec la conception que l'on peut avoir d'un code propre
qu'est ce que j'ai pointé du doigt?
du point de vue developpement on cherche a étre adapté a un harware relativement récent. on ne planifie pas de ve pour atari st par exemple
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
j ai lu dans les posts précédent que la différence était surtout énorme au temps des 486 , je pense que ça doit dater de cette période mes tests ...
faudrait que je refasse une batterie de test pour être plus sur
pour dire de changer de langage , si le client demande pas mal de fonctionnalité récente et utilise xp sur ce type de pc (même pas toujours avec + de 256 méga de ram ) que faire ? En europe je n'ai a mon souvenir jamais été confronte à un tel soucis cote performance du pc ... mais voila je ne suis plus en europe et je doit me satisfaire de ce que je trouve cote matos chez mes clients
tu peux aussi les prévenir que c'est une connerie d'installer xp sur une machine trop petite.
tu peux te réfugier derriere les minimum requirement du système peu être ....
http://www.microsoft.com/windowsxp/sysreqs/pro.mspx
encore que
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
au temps pour moi... Rendons à césar ce qui lui appartientqu'est ce que j'ai pointé du doigt?
du point de vue developpement on cherche a étre adapté a un harware relativement récent. on ne planifie pas de ve pour atari st par exemple
C'est bien atc666 qui pointait du doigt la difficulté d'avoir du matériel "récent"
Delphi passera très bien ! Tu pourrais aussi faire du C/C++ mais tu n'auras pas le même confort/facilité de développement en C++ qu'en VB.
Pour XP, 256 Mo de RAM c'est plus que suffisant !
En quoi est-ce que ça contredit ma description du processus ? PHP commence bien par transcrire son programme écrit en forme compilée sans commentaire, donc lors de l'exécution (après la compilation), la quantité de commentaire ne joue plus. Evidemment, ce n'est valable que pour une exécution, donc le phénomène que tu décris est effectivement un fléau si tu n'utilises pas un framework qui maintiendra en mémoire les formes compilées de tes pages dynamiques (c'est l'un des cas que j'ai décrit dans ma réponse explicitement d'ailleurs), non que ces solutions soient toujours une panacée comme tu le soulignes (note bien que ceci n'est pas un éloge de PHP, c'est un langage que j'abhorre).
--
Jedaï
Ca ne contredit pas ta description. Mais tu laisses entendre que pour PHP, dans le cas général l'impact des commentaires est négligeable, et tu présentes le cas où ça ne l'est pas comme un exception.
Moi je dis que très souvent, en PHP, tu te retrouves vite à parser une quantité phénoménale de source pour n'exécuter que quelques lignes. Et c'est plutôt le cas où le temps de parsing est négligeable qui est exceptionnel.
D'autant plus qu'en PHP, tu peux faire tes includes dynamiquement en les conditionnant avec des variables, ce qui rend l'utilité des caches d'opcode très discutable...
Il existe également des directives telles que include_once et require_once qui permettent suivant comment d'éviter d'inclure un fichier qui aurait déjà été inclus par un autre fichier inclus (vous me suivez
J'ai du créer un exemple d'utilisation en PHP du service que mon entreprise développe, j'ai choisi une approche objet avec une philosophie 1 classe = 1 fichier.
Les includes entre les fichiers de classes sont vite devenus un plat de spaghettis carbonara, j'ai même eu des situations ou les pages marchaient par bol parce que par hasard l'un des fichier nécessaire au fonctionnement d'une classe avait été inclus dans le script final depuis complètement ailleurs!
Quand on a l'habitude d'un langage typé et compilé, le PHP est vite pénible...
C'est justement parce que include_once et require_once sont excessivement lents !Il existe également des directives telles que include_once et require_once qui permettent suivant comment d'éviter d'inclure un fichier qui aurait déjà été inclus par un autre fichier inclus (vous me suivez
On a obtenus des gains de perfs de 30% en remplaçant les include_once par des include standards, et en testant préalablement si le fichier n'avait pas déjà été inclus avec une variable globale (comme on le fait en C avec les .h et les directives de compilation).
Finalement, on a eu une lueur d'espoir avec l'autoload de class en php. Malheureusement, c'était trop tard pour le projet...
Impressionnant!
Je pensais pourtant que ça leur coûterait pas cher de mettre le fichier dans une structure de type hash set histoire de vérifier s'il a déjà été inclus ou non...
Je vais passer pour un con mais je trouve ça assez affligeant qu'on doive en venir à ta solution pour un truc à priori aussi simple.
Ouais. Lorsqu'on nous a dis qu'il fallait éviter les include_once pour les perfs, j'ai pris les mecs qui nous le disaient pour des charlots, (comme pour ceux qui s'empressaient de dire : remplacer les foreach par des for, les double-quote par des simples quote...) persuadé que même si c'était réellement plus rapide, ça n'allait pas révolutionner les performances.
Et puis a force de mesurer des temps de traitements d'includes à 60% du temps complet de la page (malgré des requêtes SQL au milieu) on a finit par faire le test ! Maintenant, le traitement des includes ne dépassent pas 40% du temps d'exécution complet de la page.
Je trouve ça aussi complètement effarant. Surtout que le hashmap c'est quand même la structure de données (voir la seule) qui est à la base de tout php. Ils ont dû se dire que le fichier a pu être modifié entre deux includes...
Messieurs, on digresse, là, on digresse...
Cependant, et bien que je m'en veuille de continuer dans cette voie, je tiens à signaler que la manière d'éviter les inclusions multiples est toute autre en C (et en C++)...
Le principe n'est en effet absolument pas basé sur une variable globale, mais sur un symbole défini par la compilation, pour la compilation, et qui ne subsiste absolument pas dans l'exécutable une fois la compilation terminée
En effet, une variable globale aura un cout (même minime) au sein de l'exécutable compilé, alors que les symboles qui servent de gardes anti inclusion multiple n'en ont strictement aucun (d'ailleurs, c'est bien simple: ils sont "oubliés" même par le compilateur une fois la compilation de l'unité en cours terminée
Tu as tout a fait raison.
Je faisais allusion au fait qu'on commence par tester quelque chose pour savoir si on doit faire l'include. Comme tu le dis, en C se sont des define, traités par le preprocesseur, qui n'ont ensuite aucun effet une fois le code compilé.Cependant, et bien que je m'en veuille de continuer dans cette voie, je tiens à signaler que la manière d'éviter les inclusions multiples est toute autre en C (et en C++)...
En PHP, il n'y a pas de preprocesseur, donc on doit le faire dynamiquement avec des variables globales, ce qui n'est pas tout à fait aussi bon... mais moins mauvais que ce que fait PHP.
Un code propre est tout simplement un code compréhensible par un autre développeur
Tres certainement... Nous sommes tous bien d'accord là dessus
Le but de ce débat est, cependant, justement de déterminer ce qui rend un code compréhensible par un autre développeur
Ce qui aurait été sympa, c'est que tu donnes ton avis sur ce point
Bonjour.
J'irai plus loin : Un code propre est tout simplement un code compréhensible par tous les développeurs du monde.
C'est ici que ça coince...
Mon professeur de programmation disait que l'on pouvait connaître la personnalité du programmeur, juste en regardant son code. Etant donné que tous les développeurs n'ont pas la même personnalité et qu'elle est changeante, et que certains langages permettent de faire des choses de plusieurs façons, la réponse ultime me semble insoluble. "A moins de vouloir robotiser la fonction"...
On peut approcher à quelque chose d'ultime avec des conventions, etc...
Mais ce sera alors difficile de faire face à l'évolution constante du matériel et des API de développement, et j'en passe et des meilleurs.
Une réflexion vue sur un blog sur la sécurité informatique: "rien n'est acquis". Un code propre doit s'adapter. Ce qui est propre un jour, ne l'est plus le lendemain.
PS: néanmoins certains passages sont obligatoires, comme celui de se poser la question "Qu'est-ce qu'un code propre". Les contextes donneront certainement des réponses différentes, mais avoir connaissance des contextes et des réponses est enrichissant.
Open Source Microsoft MediaFoundation
https://github.com/mofo7777
http://jeux.developpez.com/faq/directx/?page=dshow
un code lisible et simple
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