> J'avais lu, de mémoire qu' un code éxécuté dans une fonction est 10
> fois plus lent que le code exécuté inliné (pour le php).
C'est une stat qui ne veut rien dire. Ca a du être fait en faisant 10000 fois 1+1 dans une boucle et en comparant avec autant d'appels de fonction qui font chacune 1+1.
Dans un cas réel on est très loin de ces chiffres, et non, si tu fais une fonction qui appelle une fonctiton qui appelle une fonction, ton code n'est pas magiquement 1OOx plus lent, heureusement.
> pour remplacer les "" par des '' (pour gagner un peu de performance),
> réutiliser les même liens aux bases plutôt que de les recréer (je
> n'utilise pas les p_connect pour alléger la charge de la base de
> donnée) car même 1 seconde seulement de gagné (tout confondu:
> accès sql + traitement sql + php + transmissions html) est 1 seconde
> de gagné pour l'expérience utilisateur
Ou comment perdre du temps pour rien.
L'histoire du " => ' c'est vrai, mais globalement ça fait gagner des dizièmes de millisecondes au mieux. Si tu gagnes 15s de proc à la fin de la journée tu peux estimé avoir eu une chance extraordinaire. Si tu regardes le temps passé, le smic horaire, tu auras plus vite fait de changer de proc ou rajouter un serveur en load balancing que t'amuser à reprendre tous tes délimiteurs de chaine. Je ne parle meme pas du fait que le " => ' est vrai pour des chaines statiques. Si tu as des remplacements de variables, un "xxx $var xxx" n'est pas plus lent que 'xxx '.$var.' xxx', au contraire. Bref, du temps de perdu pour rien, et autant de possibilités de bugs et régressions si tu fais des erreurs.
L'idée de mutualiser les connect() pour le pas faire plusieurs connexions est encore pire. Mysql réutilise déjà les liens vers la base. Fais 150 mysql_connect() dans le même script avec les mêmes paramètres, PHP n'ouvrira qu'une seule connexion et te renverra toujours le même identifiant. Tu viens donc de repasser tout ton code pour refaire coté utilisateur ce que mysql fait déjà en interne tout aussi bien et probablement plus rapidement, heureux ? Peut être que si ton code était mal organisé tu faisais un peu trop d'accès aux fonctions de connexion là où un attribut de classe aurait été avantageux, mais aller faire la chasse aux connect() n'a aucun sens, ça ne changera rien aux ressources utilisées.
Et tu as quoi comme application pour que ça nécessite d'aller faire des revues de code pour gagner les quelques microsecondes de " => ' ou pour considérer que tu ne peux te permettre de réutiliser des codes existants ?
Heureusement cette mode des performances par les performances est passée. Je ne dis pas qu'il est bon d'ignorer les perfs, ni que les perfs ne servent à personne, mais ce genre de bidouilles qui font gagner 3ms/jour pour 3h de travail ça n'est efficace pour personne, même pour des boites comme yahoo.
[^] # Re: contre
Posté par Éric (site web personnel) . En réponse au journal Petition MYSQL chez Nerim. Évalué à 1.
> fois plus lent que le code exécuté inliné (pour le php).
C'est une stat qui ne veut rien dire. Ca a du être fait en faisant 10000 fois 1+1 dans une boucle et en comparant avec autant d'appels de fonction qui font chacune 1+1.
Dans un cas réel on est très loin de ces chiffres, et non, si tu fais une fonction qui appelle une fonctiton qui appelle une fonction, ton code n'est pas magiquement 1OOx plus lent, heureusement.
> pour remplacer les "" par des '' (pour gagner un peu de performance),
> réutiliser les même liens aux bases plutôt que de les recréer (je
> n'utilise pas les p_connect pour alléger la charge de la base de
> donnée) car même 1 seconde seulement de gagné (tout confondu:
> accès sql + traitement sql + php + transmissions html) est 1 seconde
> de gagné pour l'expérience utilisateur
Ou comment perdre du temps pour rien.
L'histoire du " => ' c'est vrai, mais globalement ça fait gagner des dizièmes de millisecondes au mieux. Si tu gagnes 15s de proc à la fin de la journée tu peux estimé avoir eu une chance extraordinaire. Si tu regardes le temps passé, le smic horaire, tu auras plus vite fait de changer de proc ou rajouter un serveur en load balancing que t'amuser à reprendre tous tes délimiteurs de chaine. Je ne parle meme pas du fait que le " => ' est vrai pour des chaines statiques. Si tu as des remplacements de variables, un "xxx $var xxx" n'est pas plus lent que 'xxx '.$var.' xxx', au contraire. Bref, du temps de perdu pour rien, et autant de possibilités de bugs et régressions si tu fais des erreurs.
L'idée de mutualiser les connect() pour le pas faire plusieurs connexions est encore pire. Mysql réutilise déjà les liens vers la base. Fais 150 mysql_connect() dans le même script avec les mêmes paramètres, PHP n'ouvrira qu'une seule connexion et te renverra toujours le même identifiant. Tu viens donc de repasser tout ton code pour refaire coté utilisateur ce que mysql fait déjà en interne tout aussi bien et probablement plus rapidement, heureux ? Peut être que si ton code était mal organisé tu faisais un peu trop d'accès aux fonctions de connexion là où un attribut de classe aurait été avantageux, mais aller faire la chasse aux connect() n'a aucun sens, ça ne changera rien aux ressources utilisées.
Et tu as quoi comme application pour que ça nécessite d'aller faire des revues de code pour gagner les quelques microsecondes de " => ' ou pour considérer que tu ne peux te permettre de réutiliser des codes existants ?
Heureusement cette mode des performances par les performances est passée. Je ne dis pas qu'il est bon d'ignorer les perfs, ni que les perfs ne servent à personne, mais ce genre de bidouilles qui font gagner 3ms/jour pour 3h de travail ça n'est efficace pour personne, même pour des boites comme yahoo.