Jump to content
Sign in to follow this  
Captain FLAM

Appel aux AVIS des Développeurs pour Optimisation du Core

  

12 members have voted

  1. 1. Cette proposition est :

    • Une Excellente idée !!
      9
    • Je n'ai pas les connaissances nécessaires pour répondre
      2
    • Nulle à chier ...
      0
    • A quelle heure passe le Bus ?
      2


Recommended Posts

.

!! 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 :ph34r: (surtout côté Front, le + important pour le client) :wub:

 

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@ 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 :

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 ;)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 !

 

2009-08-05-optimize-any-code-10x-faster.png

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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 ;)

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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: :rolleyes:

Share this post


Link to post
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×
×
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More