Discussion :

[clavier12AZQSWX]

PHP 7 va améliorer les performances des applications avec un gain de l'ordre de 100 %

ce genre de titre me fait très peur.

peur parce que ça veut dire que les versions précédents n'étaient pas vraiment optimisées et comportaient donc des légèretés dans la programmation.
ça me rappelle ces news que je voyais pendant 3ans sur les mise à jour des pilots ATI-AMD, chaque moi ça indiqué 10% de gains en plus donc au bout de 3ans, avec la même carte graphique on avait une carte 10x plus puissante qu'à l'achat

bref un gain de 100% me laisse perplexe et j'ai peur que PHP rentre dans une course marketing à "au numéro de version qui a la plus grosse" comme c'est le cas avec les numéros de broswer....

[RyzenOC]

ça me rappelle ces news que je voyais pendant 3ans sur les mise à jour des pilots ATI-AMD, chaque moi ça indiqué 10% de gains en plus donc au bout de 3ans, avec la même carte graphique on avait une carte 10x plus puissante qu'à l'achat

J'ai une carte graphique amd HD 5000 et je confirme que la carte et 10* plus puissante qu'en 2009 ou je l'ai acheter.
L'année dernière par exemple je peinait a faire tourner far cry 4, depuis que j'ai mis les pilotes béta (15.4) il y'a 2 semmaine bizarrement, je joue en élevée sans lag...
Et c'est un exemple de jeu parmi tant d'autre.
Y'a aussi un autre facteur dans mon cas, les ancien pilotes (12 et 13.x) supportait mal amd overdrive, je pouvais pas booster ma carte a fond, avec le 15.4, j'overclock ma carte a fond, se qui peut jouer aussi.


Pour en revenir au sujet, php ne sort une version majeur tous les ans, php5 est sortie en 2004, depuis 2009, tous les éditeurs de logiciels se sont mis a l’optimisation, intel par exemple qui a arreter sa course au Ghz, pour ce concentrer sur leurs architecture, Windows (comparons windows 7 et 8 par exemple), etc...

En 10 ans (2004, 2015), le matériel a énormément évoluer, php7 et donc optimiser pour fonctionner sur les machine d'aujourd'hui.


Ce qui m’inquiète, c'est que les débutants en herbe nous pondent du code mal optimiser car "on s'en fou, le langage est ultra performant"

[TiranusKBX]

J'ai une carte graphique amd HD 5000 et je confirme que la carte et 10* plus puissante qu'en 2009 ou je l'ai acheter.
L'année dernière par exemple je peinait a faire tourner far cry 4, depuis que j'ai mis les pilotes béta (15.4) il y'a 2 semmaine bizarrement, je joue en élevée sans lag...
Et c'est un exemple de jeu parmi tant d'autre.
Y'a aussi un autre facteur dans mon cas, les ancien pilotes (12 et 13.x) supportait mal amd overdrive, je pouvais pas booster ma carte a fond, avec le 15.4, j'overclock ma carte a fond, se qui peut jouer aussi.


Pour en revenir au sujet, php ne sort une version majeur tous les ans, php5 est sortie en 2004, depuis 2009, tous les éditeurs de logiciels se sont mis a l’optimisation, intel par exemple qui a arreter sa course au Ghz, pour ce concentrer sur leurs architecture, Windows (comparons windows 7 et 8 par exemple), etc...

En 10 ans (2004, 2015), le matériel a énormément évoluer, php7 et donc optimiser pour fonctionner sur les machine d'aujourd'hui.


Ce qui m’inquiète, c'est que les débutants en herbe nous pondent du code mal optimiser car "on s'en fou, le langage est ultra performant"

Mais voyons les débutants sortent TOUJOURS du code mal optimisé voir pourris, quand tu à commencé ce devait être la même chose
et donc pour le code pourris ça ne devrait pas changer grand chose

[RyzenOC]

Mais voyons les débutants sortent TOUJOURS du code mal optimisé voir pourris, quand tu à commencé ce devait être la même chose
et donc pour le code pourris ça ne devrait pas changer grand chose

Oui mais ils risquent de le faire expres.

Je rappelle que PHP souffrent d'une mauvaise réputation (un langage pour les nul) a cause de ces gens la, dont moi je faisait partie quand je débutant, je l'avoue.
Avec un titre pareil, les mauvais développeur dirent de s'en foutre maintenant de l'optimisation.

[TiranusKBX]

un code de merde donneras toujours des perfs de merde
ce seras juste un peut moins lent

[Spartacusply]

Avec un titre pareil, les mauvais développeur dirent de s'en foutre maintenant de l'optimisation.

La première étape pour un mauvais développeur n'est pas d'optimiser son code, c'est déjà de devenir un bon développeur.

[clavier12AZQSWX]

Oui mais ils risquent de le faire expres.

Je rappelle que PHP souffrent d'une mauvaise réputation (un langage pour les nul) a cause de ces gens la, dont moi je faisait partie quand je débutant, je l'avoue.
Avec un titre pareil, les mauvais développeur dirent de s'en foutre maintenant de l'optimisation.

php souffre de lourdeur souvant à cause de gens qui font ça :
$tab étant un tableau multidimentionnel de 1M de valeurs de tuples

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
for ($i = 0; $i <= len($tab); $i++) {
    echo $i;
}

au lieu de ça qui est beaucoup mieux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
$b= len($tab);
for ($i = 0; $i <=$b; $i++) {
    echo $i;
}

la dernière fois que je débuggais/cherchais d'où provenaient des surcharges et goulots sur un serveur qui coutait cher en interruption/upgrade c'était à cause de multiples lignes de mauvais code comme ça.

Sauf erreur et si le programme de l'éducation française n'a pas changé, on apprend l'intérêt crucial de la différence de ces lignes de code en licence informatique pur. (bac+3).

ce genre d'optimisation produit entre 25 et 50% de gains en vitesse et en baisse de charge d'un serveur.

Pour ceux qui ne comprennent pas la différence entre les deux ptits bouts de code du dessus, interrogez-vous sur vos capacités intellectuelles...et j'espère que vous n'avez pas inscrit expert php dans votre CV.

[Spartacusply]

Je te propose encore mieux (tu vas voir ça va changer ta vie) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
foreach ($tab as $i => $value) {
    echo $i;
}

[clavier12AZQSWX]

Je te propose encore mieux (tu vas voir ça va changer ta vie) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
foreach ($tab as $i => $value) {
    echo $i;
}

oups, t'as pas bien dû comprendre la réelle différence entre les deux codes. le but était de ne pas avoir à utiliser $tab et surtout pas à le parcourir ni le compter pour rien durant chaque tour de boucle quand la condition est évaluée. c'est pour cela qu'il a été sorti de la condition et dont son nombre a été compté et stocké à part.

ta solution nécessitera hélas un accès mémoire en plus dans le registre.

si tu dois faire 10000 fois le tour d'un stade, tu va pas prendre avec toi ton lourd sac de sport sous prétexte de dedans il y a écrit combien de fois tu dois faire de tour ! non. tu le regardes une fois et tu le mémorises dans un coin et tu laisses ton sac encombrant sur le bord de la piste !

[Spartacusply]

Bien évidemment que si j'ai compris la différence entre tes deux propositions. Mais la meilleure (et la seule bonne solution que devrait utiliser un bon développeur) est la solution du foreach car non seulement c'est la plus propre mais également la plus rapide dans tous les cas (je sais pas où tu vas chercher ton accès mémoire supplémentaire, d'ailleurs accès mémoire dans le registre ne veut rien dire du tout...).

Foreach fonctionne avec un pointeur interne qui se déplace à chaque tour de boucle, à aucun moment la taille du tableau n'est calculé. Or déplacer un pointeur est plus rapide qu'effectuer une comparaison, d'où la différence de rapidité.

... et j'espère que vous n'avez pas inscrit expert php dans votre CV.

Et j'espère que toi non plus tu n'as pas écrit expert Php sur ton CV.

[Gugelhupf]

A mon avis en passant du len($tab) à la boucle foreach il y a un léger quiproquo dans votre conversation. C'est sûr qu'utiliser len($tab) aura un coût à chaque itération, mais je pense que beaucoup le savent déjà.

Sinon je pense que @clavier12AZQSWX part du principe que la boucle "foreach" doit gérer les clés en plus des valeurs par rapport à la boucle "for", mais rien ne prouve que l'implémentation de la boucle foreach donne des résultats moins performants que l'utilisation de la boucle for.

Je vous invite à créer vos benchmarks en indiquant votre version de PHP et de nous montrer vos résultats accompagné du code

[clavier12AZQSWX]

Bien évidemment que si j'ai compris la différence entre tes deux propositions. Mais la meilleure (et la seule bonne solution que devrait utiliser un bon développeur) est la solution du foreach car non seulement c'est la plus propre mais également la plus rapide dans tous les cas (je sais pas où tu vas chercher ton accès mémoire supplémentaire, d'ailleurs accès mémoire dans le registre ne veut rien dire du tout...).

Foreach fonctionne avec un pointeur interne qui se déplace à chaque tour de boucle, à aucun moment la taille du tableau n'est calculé. Or déplacer un pointeur est plus rapide qu'effectuer une comparaison, d'où la différence de rapidité.



Et j'espère que toi non plus tu n'as pas écrit expert Php sur ton CV.

mais non, tu n'as pas compris mes deux exemples. je ne veux pas acceder aux données du tableau, je veux juste faire une itération . Foreach est inutile et encombrant dans ton code donné car on se fiche des valeurs de $tab.

[ABCIWEB]

mais non, tu n'as pas compris mes deux exemples. je ne veux pas acceder aux données du tableau, je veux juste faire une itération . Foreach est inutile et encombrant dans ton code donné car on se fiche des valeurs de $tab.

Bah tu pars d'un exemple qui n'a aucun intérêt pratique pour dire qu'on ne comprend rien... Pas convaincant comme exemple. Et puis on utilise quasiment jamais la syntaxe for... en php, simplement parce que l'on en a pas besoin (y'a pratiquement toujours mieux à faire).

Sinon le fait que php gagne en performance ne veut pas dire que les versions précédentes "comportaient donc des légèretés dans la programmation". Les programmes doivent bien sortir dans un temps donné. Ensuite on trouve des idées à droite ou a gauche pour encore les améliorer. C'est ce qui s'appelle le progrès et les langages informatiques tout comme les objets réels suivent cette évolution. Y'a pas de quoi avoir peur de ça

[RyzenOC]

Oui enfin, faut pas non plus rentrer dans l'optimisation extrême, aujourd'hui sur nos serveurs actuel (même sur un raspbery par exemple) comparer un for et un foreach, je trouve cela ridicule, c'est pas en remplacent un for par un foreach que le serveur vas gagner en perf, c'est plutôt ce qu'il y'a dedans qu'il faut regarder.

[ABCIWEB]

Oui et puis la syntaxe "for" pour lister un tableau est typiquement une syntaxe javascript. Php dispose de fonctions incomparablement plus évoluées que javascript pour traiter des tableaux alors le commencement de l'optimisation est de les utiliser...

[TiranusKBX]

après si tu parle js tu à

Code Javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
 
var obj = {a:1, b:2, c:3};
 
for (var prop in obj) {
  console.log("o." + prop + " = " + obj[prop]);
}
 
// Affiche dans la console :
// "o.a = 1"
// "o.b = 2"
// "o.c = 3"

mais ça ne donne que les clés/variables et on à accès direct à l'objet ...
ou alors direct les données

Code Javascript :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
arr = [3, 5, 7];
 
for (i of arr) {
   console.log(i); // affiche "3", "5", "7"
}

[abriotde]

Le support Unicode est je pense (je l'espère) totalement abandonné. L'idée aurait été de permettre d'utiliser des noms de variables avec n'importe quel caractère. Cela a 2 gros défauts rédhibitoires :
1) Une baisse de performances de manière intrinsèque. Or quoiqu'on ai put dire les performances d'un langage compte énormément. C'est ce qui empêche certains de percer (Ruby) et permet à d'autres de s'imposer ou tout du moins de rester (C).
2) Un code non propre. L'informatique est génétiquement anglais, et a l'heure de la mondialisation mettre des caractères chinois et des caractère russe pour des noms de fonctions est empêcher un étranger de relire le code, c'est du code sale.

[ABCIWEB]

@TiranusKBX

Merci pour l'info, avec le "of" je viens de voir que javascript tente enfin de faire évoluer ses fonctions de traitement des tableaux. C'est pas du luxe

Enfin bon le temps que tous les navigateurs s'y mettent ça va prendre un certain temps et je ne me risquerai pas à cette syntaxe avant longtemps. Ce qui est pratique avec les langages serveur c'est qu'on peut profiter immédiatement des nouvelles fonctionnalités. Alors bienvenue à php 7 (et longue vie à jquery)

[Tsilefy]

Le support Unicode est je pense (je l'espère) totalement abandonné. L'idée aurait été de permettre d'utiliser des noms de variables avec n'importe quel caractère.

??
Sur un bon vieux PHP 5.4 (sans la balise code de l'éditeur qui transforme unicode)

<?php

$ಠ_ಠ = "hello";
$♔ = "world";

echo $ಠ_ಠ. " " .$♔;


donne: hello world

[Gugelhupf]

Le support Unicode est je pense (je l'espère) totalement abandonné. L'idée aurait été de permettre d'utiliser des noms de variables avec n'importe quel caractère. Cela a 2 gros défauts rédhibitoires :
1) Une baisse de performances de manière intrinsèque. Or quoiqu'on ai put dire les performances d'un langage compte énormément. C'est ce qui empêche certains de percer (Ruby) et permet à d'autres de s'imposer ou tout du moins de rester (C).
2) Un code non propre. L'informatique est génétiquement anglais, et a l'heure de la mondialisation mettre des caractères chinois et des caractère russe pour des noms de fonctions est empêcher un étranger de relire le code, c'est du code sale.

Euh l'idée de mettre en place l'Unicode ce n'est par pour interpréter un nom de variable avec n'importe quel caractères, mais pour que les fonctions liés aux chaines de caractères contenant des caractères spéciaux puissent fonctionner correctement ...

Observe :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
<?php
 
$var1 = "Hello"; // Devrait afficher 5
$var2 = "éèàùç"; // Devrait afficher 5
echo strlen($var1) . PHP_EOL; // Affiche 5
echo strlen($var2) . PHP_EOL; // Affiche 10 !

... et qu'on n'ait plus à utiliser des fonctions tels que mb_strlen().