Discussion :

[TiranusKBX]

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

[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.

[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.

[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().

[Zefling]

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.

T'as jamais vu un bouquin de java en chinois... tout est en chinois, même les noms de variables. Puis en PHP on a toujours pu faire ça. Et franchement quand je code que pour moi, si je fous du français ça ne fera chier que moi.

[domi65]

Bonjour.

Veuillez pardonnez mon ignorance : Qu'est-ce que c'est une application full-stack ?
Merci.

[ABCIWEB]

C'est du jargon informatique pour désigner des gros framework comme synfony ou zend qui proposent une multitude de services et qui imposent une architecture. On peut les opposer aux micro framework qui ont un nombre de services réduits mais qui laissent une bien plus grande liberté d'architecture.
A l'extrême on peut construire son framework soi-même avec des bibliothèques de fonctions ce qui laisse une liberté totale mais demande beaucoup de travail.

[domi65]

Merci.

[Amine Horseman]

Les tests sur PHP 7 afficheraient des performances sans précédents
Avec des améliorations allant jusqu’à 45% par rapport à HHVM, selon Zend

La nouvelle version de PHP, à savoir PHP7, promet d’offrir des performances optimisées de l’ordre du 100% pour la plupart des applications, mais pas seulement.

Développée avec pour but d’améliorer la rapidité et l’efficacité du langage, cette prochaine version -dont la version alpha est prévue pour le mois prochain- reprend la plupart du code de la branche phpng (PHP Next Generation) qui avait pour but de créer un noyau optimisé grâce à la refactorisation du moteur Zend et le nettoyage du code de base. Mais PHP7 intègre aussi d’autres améliorations, notamment en ce qui concerne l’utilisation allégée de la mémoire, le stockage en local des threads, une nouvelle syntaxe pour les variables embarquant le typage strict ainsi que l’intégration d’un arbre syntaxique abstrait. Elle devrait également enlever le support des extensions ereg et mysql qui affichaient déjà un avertissement dans la dernière version puisqu’elles ont été marquées comme étant obsolètes.

Pour ce qui est des performances enregistrées, des tests ont montré que cette nouvelle version permettait de traiter 3 fois plus de transactions Magneto avec 30% de mémoire en moins que PHP 5.6, Wordpress est 2 fois plus rapide et nécessite 75% moins d’instructions CPU, Drupal et Laravel sont 70% plus rapides, Zend Framework 2 atteint une amélioration de 95% et SugarCRM dépasse les 110%. À noter aussi que PHP7 surpasse HHVM sur la totalité des tests effectués, même si la différence est à peine visible sur les CMS, les performances gagnées sur les Frameworks ne sont pas négligeables : 39% plus rapide que HHVM sur Laravel et 45% pour Zend Framework 2 et SugarCRM.

Pour ce qui est des langages de programmation, la différence est très nette. En effet, PHP7 est plus rapide de 243% par rapport à Ruby 2.1, 400% par rapport à Python 2.7.8 et 740% par rapport à Perl 5.18.4. Les gains en performances qu’apporte donc cette nouvelle version sont énormes, de plus, elle utilise beaucoup moins de ressources ce qui permettra d’héberger beaucoup plus de sites web sur le même serveur.

La version finale de PHP7 est attendue pour octobre 2015. Tous les programmes écrits en PHP5 devraient s’exécuter sans problème sur cette version.

Source : Zend.com

Et vous ?

Que pensez-vous de cette nouvelle version ?
Pensez-vous que les hébergeurs vont rapidement passer à PHP7 ?

[RyzenOC]

Pour ce qui est des langages de programmation, la différence est très nette. En effet, PHP7 est plus rapide de 243% par rapport à Ruby 2.1, 400% par rapport à Python 2.7.8 et 740% par rapport à Perl 5.18.4.

J'aurais préférer avoir des comparaison avec Python 3.4 que 2.7,

Il aurait été bon aussi de le comparer avec des langages plus "costaud" comme Java ou C directement.
Quel perte de performance y'a t'il entre le C et php 5.6 puis php7 ?, on peut imaginer beaucoup moins mais de combien ?

Un truc qui me plairait de faire en php, a quand la possibilité de crée des logiciels en PHP, comme en python, avec une bibliothèque graphique embarqué.

[TiranusKBX]

déjà le comparatif des langages est bien biaisé vus que python 3.4 est plus rapide que la 2.7 et l'argument "mais python 2.7 est encore majoritaire dans l'utilisation de python" n'est pas recevable vus que l'on compare les "dernières" versions et que le rapport d'utilisation python 3.x est passé au dessus des 60%

[Zefling]

J'aurais bien aimé voir ce que ça donne sur les regex, parce que perso c'est probablement ce qui ralenti le plus mon framework. (La partie template )

Il faudra que je teste ça en local. J'espère que que ça va arranger le problème de get_brower() qui est devenu horriblement lent.

[DarkBakura]

J'aurais aussi aimé des comparaisons avec d'autres langages que ceux proposés, dont la réputation n'est pas basée sur la vitesse... Même si bien sûr c'est intéressant d'apprendre que PHP7 annonce des progrès sur ce secteur, il serait bon d'avoir des comparatifs plus parlants. D'autant que d'après ce que je lis le choix de la version de Python n'est pas des plus pertinents. Dommage donc.

[Invité]

Comme dit précédemment, les comparaisons laissent un peu à désirer, cela dit même si les écarts de performance ne sont pas aussi énormes je suis content que PHP se mettre au moins à niveau des autres langages de script. En tant que dev web utilisant principalement PHP j'étais plutôt inquiet, notamment par rapport au stack javascript et à Python qui se pose en sérieux concurrent, voila qui me rassure un peu

[berceker united]

Vous vous emballez un peut trop vite. C'est de la COM de chez Zend. Ils comparent là ou ça les arranges, c'est comme si Renault faisait un teste entre une Clio et une Lamborghini Gallardo et que la Clio l'emporte sur le nombre de place assise à l'intérieur.
Relâchez vos épaules, respirez profondément, laissez tomber vos bras le long du corps et détendez-vous. Attendez les vrais testes
Zen !

[miky55]

C'est sur c'est de la com, il n’empêche que je suis plutôt confiant sur les capacités de zend à encore optimiser php, on a vu pas mal de progrès ces derniers temps et la concurrence apportée par HHVM est plutôt stimulante. Une des forces de php est la possibilité de développer des mods en natifs (C) pour des performances optimale (par ex le framework phalcon est totalement codé en C)

Par contre j'aurai aimé voir aussi asp dans ce bench.

[polaroid62]

C'est en effet biaisé sur Python et même Ruby car on ne parle même pas de framework cas d'usage plus fréquent de ces langages . Ces benchs ça fait un peu qui a la plus grosse et il est certain que ceux qui fournissent des serveurs resteront massivement sur PHP mais il faudrait aussi faire d'autres comparatifs qui par exemple donneraient un défi à des programmeurs de niveau équivalent et voir qui sera le plus efficient dans un temps donné . Un comparatif entre Rails et Symfony 2 ça me botterait bien . Une comparaison avec Node.js ça serait sympa aussi , là j'ai l'impression que les mecs font comme Apple avec l'excellent Swift : un bench qui n'est fait que pour montrer ce que l'on veut bien montrer.

[Dgamax]

PHP 7.0.0-dev tourne déjà sur nos espaces de dev et sans aucun changement de code et hardware, on double le nombre de requêtes par seconde sur nos infra.
Ce qui est déjà énorme comme gain de perf!

[Zefling]

PHP 7.0.0-dev tourne déjà sur nos espaces de dev et sans aucun changement de code et hardware, on double le nombre de requêtes par seconde sur nos infra.
Ce qui est déjà énorme comme gain de perf!

Je pense que je vais tester ça ce week-end.