Reprise du message précédent :
bon c'est finir l'enculage de mouche ici ?
si vous voulez parler d'optimisation allez sur le topac ASM d'Harko  

 
Ce post dénote de graves lacunes dans la connaissance de ce que ce sont l'analyse lexicale et syntaxique.

Un lien, une explication ?

Warning: je tente d'expliquer simplement des notions que j'ai étudiées... il y a près de 3 ans, donc il peut y avoir quelques imperfections/erreurs.
 
En gros l'analyse lexicale découpe ce qu'on lui donne en tokens, et l'analyse syntaxique construit à partir de ces tokens un arbre syntaxique, au moyen d'une grammaire.  
 
Ce procédé est à la base de tous les compilateurs et interpréteurs (dont php of course). Un compilateur transformera l'arbre de différentes façons avant de produire un résultat dans un langage différent, un interpréteur le parcourera pour exécuter le programme.
 
Pour faire l'analyse lexicale, deux solutions. Se taper l'analyseur à la main (formateur mais rapidement imbitable), ou alors le générer au moyen d'un générateur d'analyseur lexical (exemple: lex/flex).
Quand on génére un analyseur, on en écrit une description, au moyen d'une expression régulière.
En gros, on dit au générateur comment reconnaître les éléments lexicaux du langage: les chaînes de caractères, les nombres, les identifiants, les opérateurs, les commentaires...
 
Et ça se fait le plus souvent au moyen d'expressions régulières.
Pour un commentaire simple ligne: ça sera simple : /\/\/.*$/
Pour un commentaire multi-lignes ça n'est pas faisable directement avec une expression régulière. On utilise une pile d'états.
Quand on détecte le /* on passe dans un état "commentaire".
Dans cet état, on ignore tout sauf le */, dès qu'on le recontre on retourne à l'état initial. Pour les commentaires imbriqués, même principe avec un compteur.
 
Là où on peut dire qu'au niveau perfs c'est kif kif, c'est que tous les cas, l'essentiel des lignes est analysés par le moteur de regexp pour y détecter au choix la fin de la ligne, le */, le /* ou le //
 
Donc pour que ça ait une différence niveau perfs, faut aller sacrément profond. Globalement les problèmes de perfs se posent pas sur l'analyse lexicale qui est relativement simple. Plutôt sur l'analyse syntaxique.

Et dans tous les cas, la phase pouvant souffrir de problèmes sera passée depuis longtemps lorsque le script s'exécutera, puisqu'un script ne s'exécute habituellement que lorsque l'analyse est terminée.
 
Donc ce genre de trucs n'a aucune influence sur les performances à l'exécution, juste sur le démarrage de l'exécution, et elle n'est pas lourde.

Merci pour l'explication.
 
N'empêche que c'est un topic à la c.. et que sur le fond j'avais raison, il y a bien une différence même si elle est invisible.

Disons que pour faire du code propre, professionel faut quand même les respecter les petits trucs a 2€

 
Pas nécessairement. Un code propre et professionnel, c'est pas un code qui est bourré de micro-optimisations dans tous les sens.
Un code propre et professionnel, c'est un code:
- clair, simple
- respectant une norme d'écriture un minimum bien foutue
- documenté convenablement dans le code et en dehors du code
- sans défaut majeur de performance
 
Quand je parle de défaut majeur de performance, c'est un truc qui va être trop lent/trop gourmand en ressources par rapport à la volumétrie prévue.  
Si vous arrivez à avoir ça sur un projet - dans la vie la vraie, en entreprise, par pour votre CMS en PHP qui tue les mouettes - là vous pourrez vous dire que vous faites du code propre et professionnel. Et vous pourrez être fiers, parce que ça court pas les rues.

Un code propre et professionnel c'est déjà un code correct, pour commencer

Il serait plus juste de dire qu'il faut avoir de la logique dans ce qu'on fait
Et par exemple utiliser une variable qui joue le rôle d'une constante, et que souvent tout mis bout à bout sans que ça soit illisible c'est mieux que du code de goret, bien compliqué, à la complexité logique souvent seule maitresse du professionnalisme de l'ensemble  

 
C'est pas faux, mais je m'étais tenu cette caractéristique là pour implicite . J'ai trop foi en la nature humaine

HERE HERE
 
Extrêmement pas du tout con
 
On sait que :

et

Font carrément pas la même chose. En terme d'opcodes PHP, on a pour le deuxième :

et pour le premier :

 
Maintenant on a aussi des trucs genre printf, qui sont des wrapper sur les fonctions C du même nom
 
Je m'en va benchmarker

c'est "hear hear" à la base, mais bon s'pas grave

J'men fous, /b/a fini de me bouffer mon dernier neurone, je suis complètement déformaté

En même temps on s'en tape, de même que de ce bench à la con qui n'a strictement aucun intérêt parce que dans 9 cas sur 10 ce n'est pas ta création de strings qui fait se trainer l'application.
 
profiling > benchmarking

Je sais très bien, j'arrête pas de le répéter. Je voulais essayer un truc, partir dans le low level comme l'a dit magicbuzz, mais en PHP c'est pas trop la peine

On peut quand-même préciser que, pour de très très grande concaténation, l'output buffering est fortement conseillé

Ailleur non plus, à part en C.
 
Par exemple en Java ou en C#, le benchmarking est rendu extrèmement difficile par le JIT et la propension du GC a toujours se déclencher au mauvais moment

 
 
merde j ai pas compris ce que c etait jit alors
je connais pas c# mais je pensais que le fait que java soit compilé ... :s

Java et C# sont compilés, mais dans un langage spécifique dépendant de leur VM et indépendant de la plateforme (Java Bytecode pour la JVM, MSIL pour le CLR), qui est ensuite interprété (Python est aussi compilé dans en Python Bytecode, mais l'étape de compilation est largement moins violente, le Python Bytecode est plus une compression du code qu'un langage différent).
 
Ensuite, le bytecode/il est interprété par la VM et peut être dynamiquement compilé en language machine au lieu d'être simplement interprété (c'est le rôle du JIT: quand ses routines déterminent qu'une section de code est "souvent" exécutée, il compile cette section en langage machine et la stocke dans un cache, et la prochaine fois que la section est appelée il présente le code machine au lieu du bytecode à réinterpréter).
 
Le truc, c'est que le JIT ne compile pas tout (la consommation de mémoire deviendrait terrifiante, et le JIT boufferait plus de processeur qu'il n'en économiserait par ses compilations, sur le court terme en tout cas), et sûrement pas instantanément, donc les performances des sections de code dépendent non seulement des paramètres externes (la charge de la machine), mais aussi de l'avis du JIT sur le bout de code.
 
Accessoirement, il existe un "pluggable JIT" pour Python (Psyco). Il est très loin d'amener les perfs des JITs JVM/CLR (entre autre parce qu'il a nombre de code paths potentiels à gérer et optimiser, et qu'il a beaucoup moins d'infos de type sur lesquelles bosser) et il consomme énormément de RAM (par rapport au même programme Python sans utilisation de Psyco), mais le boost de perfs (CPU) est fréquement entre x2 et x4, avec des pointes de l'ordre de x100 sur de l'exécution fréquente de calculs numériques.

 
t1 c est pas ma journee je comprends rien
ce matin ca m a fait pareil dans la doc de php sur les regex ...si on fait telle ou telle connerie il y erreur a la compilation

C'est quoi le problème
 
La compilation c'est simplement la transformation d'un langage "source" à un langage "cible", ça ne veut pas nécessairement dire que le langage cible est le langage machine (le langage "cible" est habituellement "de plus bas niveau" que le langage source, mais pas toujours, enfin disons qu'avec certaines compilations ce genre de considérations n'a pas trop de sens quoi)

ok en fait je crois que j avais juste tendance a oublier ce qui pouvait se passer en coulisses ^^
bah merci en tout cas

Pour revenir au sujet. Le simple est utile lorsque vous envoyez du code HTML. Ceci évite de placer des backslash sur les paramètres ce qui rend le chaine peut lisible. Par contre pour les requêtes c'est plutôt l'inverse pour les mêmes raisons. Maintenant, entre simple et double lequelle choisir ? c'est une discution totalement stérile. Parler de gain de performance alors qu'il manque un free_result sur une grosse requête. Le pointeur d'un fichier n'est pas fermé. Utiliser des chaines de caractère pour un comportement binaire, ex  : return "oui" return "non".
Bref, arrêter de vous astiquer avec une pince à épiler.

   
 
C'est ce que je dis depuis le début, ça rentre dans un ensemble de pratiques, utiliser le plus adapté est le mieux
 
Tu mets le doigt sur un truc auquel j'avais pas pensé: le backslashe. Si on considère que c'est pour contenir une chaine html, que celle là est bien formée donc avec des guillements pour tous les attributs, ça ralonge quand même sacrément les fichiers pour rien en plus de rajouter un poil de cul de traitement    
 
Conclusion: même si en soit c'est pas grand chose, c'est conceptuellement trop et j'imagine bien que y'aura pas que ça comme indélicatesse de codage Et on revient à la théorie du 10µs +10µs+10µs +10µs... qui font 0.5s    

Bordel mais ça suffit avec cette connerie

   
Faire un ensemble de mauvais choix atomiquement insignifiants sur les matériaux fait un bâtiment qui tombe à la première petite tempête    
 
Mais qu'on en pense ce qu'on veut, ça va bien au delà des simple/double quote, c'est plutot un état d'esprit: pourquoi s'obstiner à faire le mauvais choix sous prétexte que ça change rien sur le temps d'éxécution de 10 lignes de code  

Pas comparable....

Tu as gagné le prix de l'analogie stupide du jour, et probablement de l'année, parce que j'ai rarement vu une comparaison aussi tordue, irréaliste et imbécile  
 

Mauvais choix?
 
C'est une blague?
 
Il n'y a pas de choix intrinsèquement mauvais sur ce genre de problèmes, en tout cas celui-ci n'en est pas un.  
 
Le seul véritable choix intrinsèquement mauvais est l'optimisation prématurée, la micro-optimisation sans raison, le fait d'optimiser (ou de tenter d'optimiser) sans savoir ce qu'on fait, sans avoir de données, le fait de tenter de micro-optimiser 100% de son programme ce qui au final amène plus souvent des bugs, de l'illisibilité et un manque d'optimisations véritables qu'un gain de vitesse.
 
Quand un programme est bien conçu et modulaire, il est à la fois aisé à profiler afin de savoir où les ressources sont consommées, et aisé à modifier dans un but d'optimisation si on en a besoin.
 
Mais l'histoire de l'informatique a montré de multiple fois que l'optimisation doit toujours venir à la fin, "correctness first", et qu'on ne doit optimiser que quand on a les données histoire de n'optimiser que les parties qu'il est intéressant d'optimiser (gagner 10% sur une routine consommant 50% du temps CPU total est intéressant, gagner 10% sur des opérations consommant 0.1% du temps CPU total est une perte de temps), "measure twice, cut once".
 
Maintenant, si tu veux utiliser des single quotes c'est ton problème, si d'autres préfèrent les doubles c'est le leur, c'est typiquement le genre de débats qui n'a aucun intérêt parce que le problème débattu n'existe habituellement pas dans la réalité.

Bien daccord!
C'est le genre de débat (troll??) qui abouti à chaque fois à la même chose : rien!
On est, et ne sera, jamais daccord la dessus....

Non justement, c'est un débat qui peut être clos, cf. post de masklinn qui répond parfaitement à la problématique.
 
Sauf cas particulier (genre 20 milliards d'itérations), l'utilisation de double ou single quote ne change pas grand chose. A toi de choisir plutôt question lisibilité quel est le mieux par exemple. Genre si t'as :

Ca peut être intéressant de le réécrire en  

Voir même en plus explicite :

Non justement j'ouvrais sur le vrai débat dont tout le monde sera convaincu qu'il est là et pas ailleurs mais j'ai du mal m'exprimer
 
Quand je parle de mauvais choix, c'est ce que je dis depuis le début, c'est à dire que c'est pas simple mieux que double ou double mieux que simple, c'est celle la plus adaptée à ce qu'on fait
 
Pourquoi s'entêter à vouloir faire  

si y'a rien à évaluer plutot que ce qui semble logique cad:

 
Mais aussi pourquoi se border aux simple quotes quand on a besoin des double et tomber dans l'excès inutile de concaténation genre:

Alors qu'un simple

sera bien plus lisible et probablement plus efficace si on parle de grosse quantité de lignes
 
 
Je suis tout à fait convaincu que le simple est pas le mieux (le mieux pour quoi ), je veux juste dire que c'est pas pour autant que le double est mieux(toujours pour quoi ), que c'est juste comme pour tout le reste: suffit d'appliquer ce qui est le plus logique pour ce que l'on fait
 
Alors en résumé prendre des bonnes habitudes de codage propre ça peut pas faire de mal à l'échelle d'un projet sans tomber dans la suroptimisation, ce que ça n'est pas mais plutot le contraire à savoir ne pas tomber dans la lourdeur généralisée.
 
J'ai surement été traumatisé par le premier projet écrit en php que j'ai vu de ma vie, un gros tas de truc non réfléchis atomiquement parlant, aucune convention d'écriture, des echo partout... Un gros tas de merde parce que justement personne s'est soucié de ce qui était mieux ou moins bien, donc au final passé 20000 lignes de code, ça a donné une grosse bouse à refaire pour que ça marche...

  Au boulot je remet le developpeur en place directe si je vois ce genre de chose.
Toi ça se voit que tu fais que tu php. Pour deux raisons qu'il n'est pas préférable de faire ça. Tu dis que c'est illisible ? Déjà tu donnes un exemple assez tordu et montre qu'il y a en amont un problème de conception mais soite.
1 - Si tu fais une lecture en diagonale le code tu ne verras pas qu'il y a une variable dans la bloque de chaine de caractères donc ce n'est pas lisible. Une variable n'est pas une chaine de caractère.
2 - 99% des autres languages ne permette pas se genre de chose. Quand tu fais plusieurs languages tu vois tres vites qu'il faut developper de manière commune ceci pour éviter de confondre les suptilités.

C'est le cas si t'as un éditeur pourrave. Les vrais pigent qu'il y a une variable dans la string et colorent comme il faut

Tous les éditeurs de qualité sont capables de recolorer ce genre d'expressions afin de rendre leur présence visible et explicite.
 
Exemple: emacs, ruby-mode

Si tu arrives à rater les interpolations avec un truc pareil, faut t'acheter des yeux.
 

Pardon? Développer de manière commune dans tous les langages? Genre faire du fortran dans tous les langages?
Désolé mais non, dans un langage donné il faut développer avec les idiômes du langage, sûrement pas avec les idiômes d'un autre langage, ce qui serait le meilleur moyen de se vautrer et de faire n'importe quoi (genre utiliser les idiômes Java quand on code en Ruby ou en Python).
 
Des standards de codage pour chaque langage et un style de code cohérent au sein de chaque projet ou langage je suis d'accord, mais coder de la même manière d'un langage à l'autre n'a aucun intérêt, à ce compte là autant standardiser un langage unique pour tous les projets, le gain sera notable à tous les niveaux.
 
D'autant plus que décider d'une manière commune de développer sur tous les langages, ça signifie ce restreindre dans tous les cas à un subset des opérations possibles correspondant uniquement à ce qui est partagé entre tous les langages, on perd donc l'intégralité des avantages des différents langages. Ca n'a strictement aucun sens.

Version jEdit :

Là c'est mon avis mais un éditeur n'a pas à l'interpreter puisque tu indiques que la variable est dans une chaine pourquoi la différencier bref. Pour moi c'est un non sens de php de laisser cela. J'espere qu'avec la version 6 ils decideront de rendre cela incompatible.
C'est pas parce que php laisse des chose que c'est forcement correcte.
 
T'as pas compris le deuxieme point. Quand tu fais plusieurs language il est tres facile de s'emmeler les pinceaux. les languages dans la plupart des cas sont sur une base communes. Pour éviter de trop confondre il est préférable de rester sur le zone commune. je m'en rend bien compte car je fais du  php, asp, c#,java, javascript et lorsque dans la meme journée on jongle de l'un à l'autre les erreurs arrive tres vite. Pour en revenir au guillement. Quasiment tous les autres language utilise le double quotes et il n'est pas possible d'insérer une variable à l'intérieur sans concaténation.

Ben justement parce que le langage fait la différence

 
C'est PHP, si PHP fait quelque chose, alors c'est correct en PHP