J'avoue que je suis m�ga retissent � ce genre de pr�sentation, je pr�f�re de loinCitation:
Envoy� par Kioob
car elle est tr�s lisible, on voit de suite le code compris dans l'acolade.Code:
2
3
4
Version imprimable
J'avoue que je suis m�ga retissent � ce genre de pr�sentation, je pr�f�re de loinCitation:
Envoy� par Kioob
car elle est tr�s lisible, on voit de suite le code compris dans l'acolade.Code:
2
3
4
Bonjour, j'aimerais savoir si les commentaires et autres choses trucs inutiles ont une incidence sur la vitesse d'ex�cution d'une page appel�e tr�s souvent.
Dans mon cas, il s'agit d'un script d'environnement appel� tr�s tr�s souvent g�rant mon site (il s'agit d'un jeu en php, le script g�rant par exemple l'IA des cr�atures)
Un matin je me suis lev�, et j'ai liquid� tout commentaire, indentation, etc... Le fichier est pass� de 80ko � 50ko
Le fait est que le fichier peut �tre appel� plusieurs centaines (milliers de fois ?) par jour, ce qui repr�sente autant de fois 30ko de moins de charg�.
J'ai fait de m�me sur les pages principales (les plus vues par les visiteurs).
Je suis conscient que php comme les autres compilateurs ignorent les commentaires en compilant, mais contrairement aux autres langages, on obtient pas de fichier "compil�", et donc je me suis dit qu'� chaque fois le serveur rechargeait en ram le fichier complet, et donc si un fichier de 100 ko est vu par 10 visiteurs en meme temps, le serveur prendra 1 Mo en gros de ram pour les compiler.
Je voulais savoir si dans l'id�e c'�tait int�ressant, ou si ct inutile (par exemple si les serveurs �taient de base optimis� pour �viter de recompiler 15 fois les m�mes fichiers en ne gardant qu'une occurence du fichier d'origine en ram) ?
Autre question que je n'ai pas vu ici (j'ai lu les 10 pages :p) :
Je d�coupe �norm�ment mes sources (pour mon jeu, j'en suis � 700 pages php) de fa�on � pouvoir retoucher plus facilement telle ou telle partie. Mais du coup je suis confront� � un soucis : include ou require ? include_once ? require_once ?
je me retrouve souvent avec 4 ou 5 require en d�but de fichier (suite au test de session ou autre). Il y a assez peu de page ou un fichier est inclu "forc�ment", j'ai donc opt� pour le require. Mais dans le cas par exemple du fichier de connexion (pratiquement appel� partout), ne vaut il pas mieux appeler include ? Avec 2 ou 3 millions de pages vue par mois, et les 2/3 avec un appel � ce fichier, m�me si c quelques millisecondes, �a peut finir par �tre un gain de temps (et le contraire aussi niveau perte m�moire, etc...). Pour les *_once, sont ils vraiment utiles si on compare � un simple "function_exists" d'une fonction pr�sente dans le fichier � inclure ? (par exemple une page peut �tre appel�e � partir d'une ayant d�j� d�clar�e une fonction, et d'une autre ne l'ayant pas fait)
voila voila... merci :)
Hello,
oui les commentaires et autres "choses trucs inutiles" ont une l�g�re incidence sur le temps de "compilation". Mais ce n'est pas pour �a qu'il faut les supprimer !!! Le plus sage est plutot d'installer un cache d'opcode (Turck MMCache par exemple) qui �vitera � PHP de recompiler le script syst�matiquement.
Pour les inclusions, require et include sont quasiment identiques depuis "belle lurette" : ce n'est que la gestion des erreurs qui change.
Quant � include_once() vs include(), la premi�re est l�g�rement plus lente, puisqu'elle inclus un test suppl�mentaire ; ce qui ne veut pas dire que tu ferais mieux autrement.
A mon avis tu ne cherches pas forc�ment o� il faut : regarde d�j� du cot� de la compression des pages, des caches HTTP, des caches de donn�es et/ou html, etc.
quand je parle de retirer tout commentaire, et autres trucs inutiles, je veux dire que j'ai 2 fois la page : la page pour d�velopper, et la page � uploader "nettoy�e" :)
�videmment, dans un soucis de d�veloppement tranquille, je garde tout :)
Le probleme des caches, c que mes pages sont identiques au niveau source, mais le r�sultat est diff�rent pour chaque visiteur (sans compter que pour les pages style forum assez visit�, il vaut mieux voir les messages en direct plut�t qu'avec un cache :p)
Sur mon forum j'ai un cache de donn�es, et un cache HTTP.... �a ne pose aucun probl�me.... quand c'est bien fait.
Et le gain est �videment �norme.
Tous les commentaires ne sont que mon avis (ou experience) ;-)
Globalement tu gagneras de la m�moire RAM, ce qui peut etre utile notamnent pour ton jeu.Citation:
Envoy� par Grey
Le must reste le cache m�me si tu risque d'avoir peu de partie cachable dans ton jeu (sauf si tu utilises un systeme de template).
Si tu veux vraiement gagner de la m�moire �vite de charger des fonction inutile.
Par exemple si tu cr�es une classe avec 10 fonction et que 95% du tps tu n'utilises que 2 fonctions, il y a surement qqch � faire pour d�coupler ta classe et ainsi gagner de la m�moire.
Attention ! Mauvaise habitude.Citation:
Envoy� par Grey
Il est pr�f�rable d'utiliser des classes test si tu veux v�rifier tes fichiers, avec un si gros projet tu gagneras du temps.
Sinon je prefere require_once() que require car on evite d'inclure plusieurs fois les fichiers (et �a prend de la m�moire)
Quel est le jeu :D
Salut,Citation:
Envoy� par Kioob
aurais tu de bons petits liens pour expliquer comment c est petites choses doivent etre mise en place ?
ca m interesse
En fait, �a se passe g�n�ralement comme �a :Citation:
Grey a �crit:
je me retrouve souvent avec 4 ou 5 require en d�but de fichier (suite au test de session ou autre). Il y a assez peu de page ou un fichier est inclu "forc�ment", j'ai donc opt� pour le require.
Attention ! Mauvaise habitude.
Il est pr�f�rable d'utiliser des classes test si tu veux v�rifier tes fichiers, avec un si gros projet tu gagneras du temps.
Sinon je prefere require_once() que require car on evite d'inclure plusieurs fois les fichiers (et �a prend de la m�moire)
include "entete"
et la page elle meme
l'entete contient l'include de connexion � la base (pour les pages de jeu qui oblige � r�cup�rer les donn�es du perso)
puis un test sur la validit� de la session, sur l'homog�n�it� des donn�es, et leur contenu (qu'elles soient toute la, etc..)
si un truc cloche, je redirige vers une page logout
sinon on continue vers la page, ou il y aura les fameux require (qui ne sont qu'une fois par page, et qui ne sont donc inclu que si le test des donn�es est pass�es)
Par contre en lisant les optimisations, je me rend compte que je pourrais optimiser les connexions � la base (un jeu g�n�rant beaucoup de connexion, vaut mieux les lib�rer d�s que plus n�cessaire, avant de lancer la construction de la page d'apr�s les donn�es r�cup)
Question :
vaut il mieux faire
** Connexion
** Requete
traitement
** eventuelle requete
traitement
** requete (derniere)
** Fin de connexion
autre traitement
ou
** Connexion
** Requete
** Fin de connexion
traitement
** Connexion
** eventuelle requete
** Fin de connexion
traitement
** Connexion
** requete (derniere)
** Fin de connexion
?
on lib�re les acc�s, mais en meme temps, �a risque de multiplier les demandes d'acc�s
je vais essayer aussi de revoir les pages ou je peux regrouper toutes les requetes en un paquet pour lib�rer plus vite la connexion, mais bien souvent elles d�pendent d'autres choses...
enfin bref, sinon comme montou je suis int�ress� par le systeme de cache :)
(je suis pas fort en admin, je fais g�rer le serveur par un tiers)
autre traitement
Pour les bases de donn�es, il faut (normalement)
- Connexion Base
Toutes les requetes
Fermeture
- Traitement des donn�es (template ou autres)
En gros, jamais fermer � la fin :wink:
Sinon pour le cache, regarde PEAR
si vous avez deux boucles imbriqu�es les une dans les autres, dans le style :
il est tr�s pr�f�rable de faire :Code:
2
3
4
5
Gain de performances garantis ;)Code:
2
3
4
5
6
Noteirak j'ai bien peur que le code que tu as post� (le second) soit faux pour plusieurs raisons:
- $i va de 0 � 256 inclus. La boucle for du premier exemple va de 0 � 255 inclus.
- dans le premier exemple, ($i<256) est �valu� 256 fois, ($j<256) est �valu� 65536 fois. Dans le second exemple, les deux conditions sont �valu�es 65536 fois chacunes, ce qui rend ton code 60% plus lent qu'une simple boucle for. (benchmark� sous PHP5.1-dev)
� priori, dans l'exemple fourni le plus rapide serait:
Code:
2
3
4
5
6
7
8
9
10
11
je m'excuse, je me suis tromp� de code pour le 1er exemple, voici le bon :
J'ai fait le benchmark, le second est 10% plus rapide.Code:
2
3
4
5
6
7
8
9
10
Pour l'histoire du 0 � 256, il doit aller de 0 � 255 inclus, ce que font bien mes deux codes, et pas aller de 0 � 256 (vu que je veux 256 boucles pour chaque).
Ce que je veux dire, c'est si vous devez imbriquez deux boucles whiles, ou deux boucles for, pr�f�rez-leur une seule avec une v�rification � la fin
Petite question d'optimisation, l'utilisation des r�f�rences avec & est elle une solution pratique ou bel et bien un gain de temps comme en C par exemple ou il est pr�f�rable d'utiliser des pointeurs ?
Je ne sais pas si cela a chang� dans les nouvelles versions, mais quand il s'agit d'une petite quantit� de donn�es les r�f�rences sont plus lentes. C'est un des ph�nom�nes curieux de PHP... :?
Non, le second ne le fait pas d�sol�. Mais c'est vrai que je me suis tromp�, ce n'est pas $i qui va de 0 � 256, c'est $j. Tu peux le v�rifier par toi-m�me. Quant � ton 3eme exemple... il ne suit pas ce que tu proposes ("une seule avec v�rification � la fin") et il est plus lent que celui que j'ai post� plus haut. Sous PHP5.1-dev, sur 2^24 (65536x65536) it�rations vides (c-�-d sans code autre que la boucle): 3.85s pour mon code, 11.73s pour ton 3eme exemple. :(Citation:
Envoy� par Noteirak
Comme je le disais ailleurs, n'utilisez pas les r�f�rences durant le d�veloppement dans un soucis de performance. Si ton code est mature (c-�-d stable depuis quelques temps) tu peux benchmarker l'utilisation de r�f�rences aux points-cl�, mais le gain est loin d'�tre syst�matique. HTH.Citation:
Envoy� par dark_genova
Un truc �vident, mais auquel on doit faire attention d�s le d�but : ne pas charger un fichier avec file() si on est pas interress� par tout son contenu.
Bonjour,
J'ai besoin d'extraire une grosse quantit� de donn�e depuis mysql pour les envoyer vers jpgraph.
Y a t-il plus rapide que le classique:
?Code:
2
3
4
5
Il va falloir que je me plonge dans le code de phpMyAdmin mais je vois que la meme requete sql met enorm�ment plus de temps � �tre ex�cut� et renvoy� dans mon script que dans phpmyadmin :-\
Essaye plut�t mysql_fetch_row. Si tu as bcp d'enregistrements �a peut am�liorer la rapidit� de ton script.
Merci de ta r�ponse. En cherchant d'avantage j'ai vu que la perte de temps �tait surtout � l'�tape mysql_query :oops: et l� je pense qu'il ne me reste plus grand chose � faire ...Citation:
Envoy� par fragmonster
Bonjour,
J'ai un script PHP que je lance manuellement grosso modo 2 fois par jour. Il fait beaucoup d'acc�s et de mises � jour � ma base mySql et du coup pendant qu'il tourne, ma base est indisponible.
Vu que mon script est vraiment s�quenc� en plusieurs �tapes bien distinctes, j'ai essay� de mettre de nombreux sleep(2) entre les �tapes mais rien n'y fait, ma base ne redevient disponible qu'� la fin du script.
C'est assez genant vu que ma base h�berge entre autre des forums. Du coup lorsque ce gros script tourne, les forums et les sites qui vont chercher des infos dans la base sont out
Quelqu'un a t il un d�but de piste ?
Merci
Optimise ton script ...
L'optimisation n'est pas �vidente.
Peux t on grouper en mysql un envoi de requetes ?
En fait mon script fais 60 fois la meme �tape (calculs divers) pour � chaque fois faire un update d'une ligne d'une table (ligne diff�rente � chaque fois)
Peut etre serait il possible d'atttendre d'avoir toutes les requetes pour les envoyer en une fois � la base ?
Tu peux faire un copie colle de ton script ici qu'on voye ce qu'il y a a optimiser ?
J'ai eut besoin il y a quelques jours de tester si la solution utilisant MySQL �tait plus rapide que la solution utilisant PHP.
Ma question �tait de tester si une ligne existait dans une table. Il ne pouvait y avoir au maximum qu'une seul ligne.
Donc vallait-il mieux s�lectionner la ligne et tester son existance avec mysql_num_rows(), ou alors utiliser la fonction COUNT() de MySQL, puis ensuite r�cup�rer un tableau avec mysql_fetch_array puis en extraite la valeur voulue ?
Pour r�pondre � cette question j'ai r�alis� un benchmark
R�sultat (pour ma machine) : une moyenne de 22 ms pour le mysql_num_rows contre 15ms pour COUNT.
(Pour ce test j'ai r�alis� 100000 it�rations allant de la requ�te jusqu'a la r�cup�ration concr�te du nombre de ligne.)
Maintenant �a peut parraitre un peu b�tat de dire que c'est plus rapide en utilisant les fonction de mysql, mais � l'origine cette question ne m'a pas parru �vidente.
Je pense donc que ceci est g�n�ralisable � la plus part des cas : pr�f�rer la solution MySQL lorsque vous avez le choix entre une solution MySQL et PHP.
J'en profite pour poser une petite question : vaut-il mieux stoquer dans une bdd les dates sous formes d'unix timestamp (dans un champ de type INT) ou un des formats de date de mysql ?
Benchmark est ton ami dans ce cas :)
Si tu utilises le format DATE de MySQL, tu pourras faire un grand nombre de calcul directement via MySQL. Et si besoin, tu pourras quand m�me r�cup�rer le timestamp UNIX, via la fonction MySQL d�di�e � cela.Citation:
Envoy� par Celelibi
Par contre si tu stockes en timestamp, tu vas �tre fortement limit� question calculs, et un grand nombre de taches risque d'etre rel�gu� � PHP.
DATETIME plutot non ?
Sinon tu perd les infos heures/minutes/secondes
La doc mysql est ton amie aussi, tr�s int�ressante je trouve :
http://dev.mysql.com/doc/mysql/en/da...functions.html
Existe m�me en francais :]
http://dev.mysql.com/doc/mysql/fr/da...functions.html
Bonsoir,
Si je veux acc�der � n donn�es, uniques, mais acc�d�es � chaque execution d'un script, vaut il mieux cr�er une table mysql rien que pour stocker ces n donn�es, ou utiliser un fichier � la place ?
Ou un genre de sch�ma similaire ?Code:
2
3
4
5
6
7
8
9
Si tu utilises �norm�ment de SELECT de ton fichier (c'est � dire de lecture) et que tu utilises relativement peut d'�criture (UPDATE, INSERT) je te conseil de passer par un fichier, mais stoque ces fichiers sous forme de tableau PHP avec var_export().
Par exemple :
Un simple include() et hop le tour est jou�.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
A part �a j'ai effectu� un benchmark qui m'a largement surpris. J'ai fait une fonction de test qui recoit de trois facon un tableau de 1000 �l�ments. Il recoit ce tableau en param�tre lors du premier test, lors du second test en global, lors du troisi�me par r�f�rence.
Je fais une it�ration de 10000 tour avec appel de fonction, le r�sultat est sans appel :
passage du tableau en argument : 5.0572290420532 secondes
passage par globalisation : 0.026066064834595 secondes
Passage par r�f�rence : 0.024504899978638 secondes
Voici le code utilis� pour le passage en argument :
J'en conclu qu'il faut fortement �viter de passer des grosses donn�es par argument � sa fonction (ce qui parait logiquie car toute la m�moirre alou�e pour cet �l�ment est pass�e � la fonction).Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
J'ai du mal m'exprimer. Je voulais dire n variables :
Variable 1
Variable 2
...
Variable n
qu'on peut coder en mysql comme une table avec deux champs "Nom Variable" et "Valeur" (ou en une seule ligne ^^ mais c'est pas beau)
effectivement, c assez impressionant ..Citation:
Envoy� par dark_genova
??Citation:
Envoy� par dark_genova
C'est surtout parce que dans une fonction, PHP travaille sur des copies des variables pass�es en param�tre (donc si tu passes un bon gros tableau en param�tre, PHP va devoir le copier)
Salut,
j'ai une question qui me turlupine :
Dois-je syst�matiquement activer la compression GZip ? Je voudrais savoir si elle correspond � un type de sites particuliers, ou bien si elle est efficace dans tous les cas ?
Je suis en train de faire un projet � la SPIP, et je me demande simplement si je dois faire une constante GZIP pour activer ou non la compression HTTP...
Merci de votre aide.
Pourquoi alors ne pas travailler qu'avec des r�f�rence ?
Est-ce un reflexe � prendre ?
A chaque tour dans la boucle tu calcule leCitation:
Envoy� par iubito
alors en le sortant avant la boucle tu le calcule une fois pour toutes.Code:sizeof($arr)
Au bout de la boucle tu aurra economis� du temps... :lun:
oui mais il arrive qu'on ne veuille pas les deux premi�res cases du tableau...dans ce cas un for est bien pratique.
Si j'ai deux tables A et B, et je veux selectionner des enregistrements de A, et quelques enregistrement de B associ�s. Du style
Vaut il mieux faire r�element la jointure externe, ou vaut il mieux tout rappattrier par une jointure interne, et trier apr�s ce que je garde ou non dans chaque enregistrement ?Code:SELECT ... FROM A LEFT OUTER JOIN B ON A.Id = B.Id AND A.Cle = 'Constante'
Code:SELECT ... FROM A JOIN B ON A.Id = B.Id
Code:
2
3
4
5
6
Bonjour,
Interessant ce sujet. Je l'ai trouv� en cherchant justement quel �tait le plus rapide entre un while et un foreach.
J'ai beaucoup vu que vous parliez de lib�rer la m�moire du server, mais cel� se fait au d�triment du CPU non ?
Donc faut il vraiment d�truire les variables temporaires � chaque fois, et lib�rer les r�sult Mysql, ce qui lib�re de la m�moire mais utilise le CPU � chaque appel de fonction ?
J'apporte ma pierre � l'�difice. Enfin... Disons mon petit caillou plut�t, mais c'est l'intention qui compte ^^ :
Lorsque vous devez compter un nombre d'enregistrement d'une table compotant un champ 'id', et que cette table ne subit jamais d'effacement (table contenant chaque connection au site par exemple, pour faire un compteur avec stats sur le pays etc.) plut�t que de faire un Where 1 et compter le nombre de lignes retourn�es, faites un Where 1 order by id desc limit 0,1
L'id retourn� est le dernier et correspond au nombre d'enregistrement puisque dans ce genre de table aucun n'est supprim�. Donc un seul enregistrement retourn� au lieu de tous.
Il est tr�s difficile de faire les bons tests de rapidit�s. Beaucoup de tests sur internet montrent que pour charger le contenu d'un fichier la fonction file_get_content est la plus rapide. En pratique, fgets peut �tre de 20 % plus rapide � infiniement plus long suivant les param�tres. 20 % sur le chargement d'un gros fichier, ce n'est pas rien.
Il y a toujours un tas de param�tres que l'on oublie, et l'optimisation n'est pas simple. Le pire est qu'elle d�pend avant tout de la machine sur laquelle le script tourne. D'une machine � l'autre, d'une configuration � l'autre, les meilleures solutions ne seront pas toujours les m�mes.