Captain FLAM Posted December 18, 2011 Share Posted December 18, 2011 . !! LISEZ le sujet AVANT de voter ... MERCI !! il y a quelques temps, j'avais envoyé cet e-mail à la Presta Team, et cette proposition est toujours en cours d'étude ... Aussi, je fais appel aux avis des développeurs (de tous niveaux) : "La plupart des CMS que j'ai utilisé font la même erreur de base : Mettre dans un seul fichier de classe (ou procédural) toute les parties du BO & du FO" Pourquoi donc compiler / exécuter du PHP inutilement concernant le Back Office pour la partie du Front Office ? ... et Lycée de Versailles ... Donc, l'idée simple pour commencer, et concernant les modules, serait de séparer le fichier en 2, et de n'appeler que celui concerné en fonction de l'utilisation : ► blockcart.php ► blockcart_admin.php Pas besoin de changer le nom de la classe ... dans le 1er, mettre les fonctions : ► smartyAssigns ► hookRightColumn ► hookLeftColumn ► hookAjaxCall ► hookHeader ► ... dans le 2ème, mettre les fonctions : ► getContent ► displayForm ► install ► ... A vue de nez : gain en compilation divisé par 2 (surtout côté Front, le + important pour le client) Oui, je sais, on pourra me rétorquer qu'il existe des "mod" de cache et des pré-compilateurs (memcached, eAccelerator, etc ...) ... Mais si on commençait par la base, c'est à dire alléger le 1er process : celui de la compilation ? Et puis, il y a aussi des tas de serveurs mutualisés (sans doute une grosse majorité) qui ne disposent pas de ces "mod" ... Cette idée nécessite des modifications en profondeur, et clairement une orientation de développement pour le futur, ainsi qu'une refonte des modules existants : Core : Sélection des fichiers à charger, en fonction de l'existence ou non du fichier "admin" Modules : Séparation en 2 fichiers, mais comme dans le Core c'est une option, cela pourrait se faire progressivement, au fur et à mesure ... Voilà, en espérant avoir été le plus clair possible ... P.S : Je n'ai volontairement pas posté dans la section développement, car je pense que tous les codeurs ne passent pas régulièrement par là-bas ... Merci de ne pas déplacer ce topic. Link to comment Share on other sites More sharing options...
Sbizz Posted December 19, 2011 Share Posted December 19, 2011 Bonjour. Votre idée est +/- bonne. Néanmoins, petit détail : PHP n'est pas un langage compilé Il est interprété. Ensuite, j'ai du mal à saisir votre approche. Dans votre module, vous pouvez de base le gérer... Vous pouvez détecter si vous êtes du côté BO ou FO, vous pouvez détecter combien de fois est appelé le fichier, etc. Le plus gros problème de Prestashop ne se trouve pas ici. Il se trouve surtout sur le fait que y'a VRAIMENT trop de requêtes qui sont faites et qui, amha, ne sont pas du tout optimisées. Link to comment Share on other sites More sharing options...
Broceliande Posted December 19, 2011 Share Posted December 19, 2011 juste un bémol captain pour le constructeur . Il est également utilisé en front , car le module est instancié pour pouvoir en exécuter les methodes génériques hook déja, et également utilisé dans certains modules pour les méthodes héritées de Module , comme l() , etc ... De manière générale , une classe sans constructeur ne peut avoir que des méthodes statiques... ça limite :s Link to comment Share on other sites More sharing options...
shagshag Posted December 20, 2011 Share Posted December 20, 2011 Bonjour, l'idée est intéressante mais je doute que cela ait un intérêt pour les performances : - blockcart.php et blockcart_admin.php héritent tous les deux de la classe Module c'est obligé, elle même hérite de ObjectModel donc du point de vue gain de compilation ça reste très minime. - pour certain modules il y a des fonctions partagées entre le FO et le BO (mis à part celles de base de la classe Module). Dans ce cas il faut créer un troisième fichier avec une classe partagée pour éviter de dupliquer le code. Le petit gain de compilation est perdu en temps d'accès au disque + traitement du nouveau fichier à mon avis. - je ne suis pas sûr que les fichiers ouvert par PHP soit entièrement compilés d'un coup ou petit à petit à la demande. - ont parle de gain en micro secondes sur lesquels il faut ajouter les optimisations déjà incluses dans php et les mod dont tu as déjà parlés. par contre pour la lisibilité du code oui ce serait bien. les hooks du front n'ont rien à faire avec ceux du back et les méthodes d'installation. Link to comment Share on other sites More sharing options...
Sbizz Posted December 20, 2011 Share Posted December 20, 2011 PHP n'est PAS compilé... Link to comment Share on other sites More sharing options...
Captain FLAM Posted December 20, 2011 Author Share Posted December 20, 2011 @ Broceliande : Je pensais plutôt à une extension de la classe @ shagshag : C'est un peu plus que quelques µ-secondes de gagnés Pense qu'il peut y avoir quelques millisecondes gagnées, et multiplie par le nombre de modules utilisés ... par contre pour la lisibilité du code oui ce serait bien. les hooks du front n'ont rien à faire avec ceux du back et les méthodes d'installation. Et un truc positif de plus !! C'est vrai qu'il y a des parties communes : 4 solutions : Rajouter un 3ème fichier : blockcart_common.php (mais temps d'accès du fichier pénalisant) Copier les parties nécessaires communes dans les 2 fichiers Séparer les "trucs" du _construct, notamment les Hooks F.O & B.O Inclure blockcart.php (F.O) dans blockcart_admin.php (B.O), mais c'est pas la meilleure solution . Désolé pour l'abus de langage de ma part (interprété = très lent, compilé avec un pré-compilateur = mieux) mais dans les 2 cas, c'est pareil : on interprète / compile du code qui n'est pas nécessaire. Accélération PHP est à la base un langage interprété, ce qui est au détriment de la vitesse d'exécution du code. Sa forte popularité associée à son utilisation sur des sites Web à très fort trafic (Yahoo, Facebook) ont amené un certain nombre de personnes à chercher à améliorer ses performances pour pouvoir servir un plus grand nombre d'utilisateurs de ces sites Web sans nécessiter l'achat de nouveaux serveurs. La réécriture du cœur de PHP ayant abouti au Zend Engine pour PHP 4 puis le Zend Engine 2 pour PHP 5 sont des optimisations. Le Zend Engine compile en interne le code PHP en bytecode exécuté par une machine virtuelle. Les projets open source APC et eAccelerator fonctionnent en tant que cache pour accélérer encore un peu la génération des pages Web. Il existe également des projets pour compiler du code PHP : Roadsend et phc compilent du PHP en C, Quercus compile du PHP en bytecode Java exécutable sur une machine virtuelle Java, Phalanger compile du PHP en Common Intermediate Language exécutable sur le Common Language Runtime du framework .NET. HipHop for PHP transforme du PHP en C++ qui est ensuite compilé en code natif. Ce projet open source a été démarré par Facebook Source : http://fr.wikipedia....A9l.C3.A9ration Every time a PHP script is accessed, PHP usually parses and compiles scripts to bytecode. Once installed, eAccelerator optimizes the compiled bytecode and caches this to shared memory or disk or both. Upon subsequent accesses to a script, eAccelerator will access cached bytecode if it is available instead of the script being compiled. This avoids the performance overhead of repeated parsing and compilation. Source : http://en.wikipedia....ki/EAccelerator P.S : N'oubliez pas de voter Link to comment Share on other sites More sharing options...
Sbizz Posted December 20, 2011 Share Posted December 20, 2011 Il existe effectivement des logiciels permettant de compiler PHP, pour en faire des EXE ou même, comme Facebook, le transformer en un autre langage (en passant, c'est pas PHP qui est compilé mais le C++ !). Interpréter un code et compiler un code, c'est loin d'être pareil et surtout, c'est loin d'avoir le même temps d’exécution. Donc restons dans le sujet, qui est Prestashop et dont le PHP est interprété et non compilé. Ton idée risque de pénaliser pas mal de modules. D'une part il faudra effectuer tous les changements que cela entraîne, ce qui est loin d'être simple et rapide. D'autre part, il faut assurer une très bonne compatibilité. À ce stade, je doute que ce soit une bonne idée, bien qu'intéressant. Car il est vrai que différencier le BO du FO est intéressant, mais Prestashop ne nous interdit pas non plus de faire des sous dossiers dans notre module. Link to comment Share on other sites More sharing options...
Captain FLAM Posted December 21, 2011 Author Share Posted December 21, 2011 Apparemment, tu n'as pas vu la dernière citation de mon précédent post Link to comment Share on other sites More sharing options...
Sbizz Posted December 21, 2011 Share Posted December 21, 2011 Apparemment, tu n'as compris ce qu'est un langage compilé et ce qu'est un langage interprété. Si on part de ton principe, tous les langages sont compilés. Python, JavaScript, SQL, JAVA, etc. or c'est faux. Un langage compilé a besoin d'un compilateur, gcc, par exemple. Ça veut dire que les fichiers sources sont convertis. En PHP, tes fichiers sources ne sont pas convertit. L’interpréteur lit le fichier au fur et a mesure. Tu as raison sur le fait que PHP fait parti des langages qui sont compilés en bytecodes (Java est LE cas le plus frappant), qui eux même sont ensuite interprétés. Mais ce n'est pas un langage compilé. Il faut bien différencier les deux. Néanmoins, je n'apportai qu'une précision sur ce fait, pas sur le fait que la rapidité d’exécution n'est pas influencé par une nouvelle méthode de codage Source: http://www.journaldu...terpretes.shtml Link to comment Share on other sites More sharing options...
Captain FLAM Posted December 21, 2011 Author Share Posted December 21, 2011 Tu as raison sur le fait que PHP fait parti des langages qui sont compilés en bytecodes Merci ! Link to comment Share on other sites More sharing options...
mexique1 Posted December 21, 2011 Share Posted December 21, 2011 Salut Je plussoie : ce que tu proposes n'apportera qu'un petit gain niveau performances, simplement en lisibilité. Oui, il peut y avoir un impact sur les perfs si ta classe fait 10 000 lignes alors que seulement 100 sont réellement utilisées, mais l'impact est négligeable... Dans mon entreprise, on a déjà eu affaire à ce genre de problème, mais c'était des libraires gigantesques... On a un peu gagné en minifiant les fichiers PHP. Since, PHP files are parsed and compiled at runtime, you should try to keep your source file sizes as small as possible. Source file size is particularly important with files that are included by other files. Only include or require files you absolutely must have. Additionally, if you only need one function in a file, consider breaking that function into its own file. One thing of interest here is that after running tests on a variety of source files with varying amounts of comments, I found that the amount of comments in a source file had no significant impact on performance. The only thing that seemed to affect performance was the amount of PHP code in the files. This seems reasonable when you consider that comments basically are ignored by the compiler, while any code must be parsed and compiled -- something that is much more time consuming. Désolé de faire du prosélytisme, mais mon petit framework Oops propose déjà un découpage plus clair des composants d'un module (et hop...) Pour ceux du fond de la classe qui n'ont pas écouté : http://www.prestasho...pour-prestashop Comme ça a été dit plusieurs fois, d'autres axes d'amélioration sont clairement identifiés, dont par exemple le nombre hallucinant d'appels à file_exists qui fait des accès disque et est connu pour être gourmand. EDIT : Et une bonne solution pour optimiser le code ! Link to comment Share on other sites More sharing options...
Sbizz Posted December 21, 2011 Share Posted December 21, 2011 La compilation en bytecodes est ridiculement petite et tenter d'améliorer les performances ne sert pas à grand chose car les performances des serveurs sont maintenant assez élevées pour ne pas en tenir compte _ hors très grosse librairie comme dit au dessus, mais elles atteignent un nombre de lignes colossal _. Link to comment Share on other sites More sharing options...
Captain FLAM Posted December 21, 2011 Author Share Posted December 21, 2011 Pour te convaincre : Additionne TOUTES les lignes de code (ne serait-ce que de la classe d'entrée (les fichiers portant le même nom que le répertoire)) , et ça te donnera une idée ... Et cette optimisation sera notamment (mais pas seulement) sensible sur les serveurs mutualisés ... Link to comment Share on other sites More sharing options...
Sbizz Posted December 22, 2011 Share Posted December 22, 2011 Comme je l'ai dit, le problème de lenteur ne vient pas d'ici. Tu proposes une idée qui est de mieux séparer les fichiers des modules, comme ça, seuls les fichiers utiles sont appelés. Or, on peut très bien le gérer si on y met du sien. Tu veux parler de lignes de code, moi je vais te parler de requêtes SQL. Active le fichier SQL dans /override/classes/ et affiche en bas de la page le nombre de requêtes exécutées : tu verras que tes lignes de code, que tu veux enlever, ne sont qu'une goutte d'eau dans un océan. Je dis pas que ton idée ne va pas réduire le temps de chargement d'une page, je te dis que c'est pas suffisant et que ça ne se verra pas, parce que les configurations des serveurs sont maintenant assez puissantes, serveurs mutualisés ou non. Link to comment Share on other sites More sharing options...
Captain FLAM Posted December 22, 2011 Author Share Posted December 22, 2011 Comme ça a été dit plusieurs fois, d'autres axes d'amélioration sont clairement identifiés, dont par exemple le nombre hallucinant d'appels à file_exists qui fait des accès disque et est connu pour être gourmand. Certes, c'est une autre optimisation ... nécessaire ! Et ça rejoint ce topic : séparer aussi ces appels pour le F.O & le B.O Tu veux parler de lignes de code, moi je vais te parler de requêtes SQL. Active le fichier SQL dans /override/classes/ et affiche en bas de la page le nombre de requêtes exécutées Tu penses bien, tous les fichiers de debug override activé chez moi en local, depuis le début Link to comment Share on other sites More sharing options...
Sbizz Posted December 22, 2011 Share Posted December 22, 2011 En quoi ça rejoint ton topic ? Justement tout le contraire ! Le fait de créer 3 fichiers pour séparer les choses implique 3 appels à file_exists, car Prestashop devra vérifier leur existence avant de tenter quoi que ce soit. Link to comment Share on other sites More sharing options...
Captain FLAM Posted December 22, 2011 Author Share Posted December 22, 2011 Faux !! Déjà, je parle de 2 fichiers ... Donc, il y a UN seul check supplémentaire à faire, étant donné que la classe de base est sensée exister ... (En clair : juste vérifier la présence de blockcart_admin.php) :rolleyes: Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now