Je lisais cette page - http://deadusful.com / Blog / Posts / 50-PHP-Optimization-TIPS-Revisited
Et l'une des recommandations était d'éviter d'utiliser des méthodes magiques, citées à partir d'un PDF de la performance ZEND qui ne donne aucune raison à sa recommandation. p>
Après une recherche de Google (et de la remontée ici à une question non liée), je me demandais si quelqu'un avait des recommandations sur ce front? P>
J'utilise __get () beaucoup dans mon code, généralement Pour enregistrer des variables que je n'utilisez pas toujours, par exemple p>
i peut avoir une table avec nom, desc, catégorie_id, time_added p>
My Get regarderait quelque chose comme ceci: P>
public function __get($name) {
switch($name) {
case 'name':
case 'desc':
case 'category':
case 'time_added':
$result = do_mysql_query();
$this->name = $result['name'];
$this->desc = $result['desc'];
$this->category = $result['category'];
$this->time_added = $result['time_added'];
return $this->{$name};
break;
default:
return parent::__get($name);
}
}
3 Réponses :
C'est vrai, ils sont plus lents ... mais la différence est si petite que la vitesse vs code est un facteur. Vaut-il la peine de s'inquiéter de la différence de développement et de maintenance plus rapide?
voir Benchmarks magiques pour statistiques
+1: Vous ne pouvez pas surcharger ce sentiment. Rappelez-vous, L'optimisation prématurée est la racine de tous les méchants ... Si vous dépensez tout votre temps à vous inquiéter des différences de vitesse minuscules, vous n'obtiendrez jamais rien. Construisez-la comme ça fonctionne pour vous, puis si vous avez des problèmes, refacteur de là. Mais la plus grande amélioration de la performance que vous pouvez faire est la transition d'un état de fonctionnement à un travail en activité. Tout le reste paresse en comparaison ...
Bravo Le lien est vraiment utile et votre point est très vrai, il est très difficile de ne pas se faire prendre dans le code préfet de vouloir et de ne jamais en libérer réellement aucun: D
Le code de maintien de l'OMHO est bien plus important que le code de haute performance. Pensez-y. Il est moins cher de lancer plus de matériel à un problème que de jeter plus de développeurs. C'est une raison que PHP est si populaire ... Maintenant, il y a toujours un compromis, alors je ne recommande pas d'ignorer les performances, mais n'essayez pas de micro-optimiser si vous ne savez pas si un problème existe .. .
@ircaxell, quel est un état non fonctionnel et quel est un état de fonctionnement?
@ kavoir.com "non fonctionnel" signifie que le logiciel ne fonctionne pas. Et le travail signifie qu'il fonctionne. Aussi simple que cela.
C'est peut-être évident, mais je pense que l'article de référence est trompeur. Il compare la performance des fonctions avec une seule instruction et déduit que des méthodes magiques sont 3X plus lentes. Supposons naïvement que chaque appel et déclaration de fonction aient un coût de 1, et des méthodes magiques ont un coût de 2. Ensuite, si vous aviez une fonction de 10 relâche à 10 relevé, le coût de la fonction est 11 sans magie et 13 avec magie, faisant de la magie seulement 1,2 fois plus lent. Ceci est probablement plus réaliste, étant donné la façon dont les gens utilisent des méthodes magiques pour déléguer.
envisagez d'utiliser ACCESSIONS Array .
class Record implements ArrayAccess {
/**
* @see ArrayAccess::offsetExists()
*
* @param offset $offset
*/
public function offsetExists($offset) {
}
/**
* @see ArrayAccess::offsetGet()
*
* @param offset $offset
*/
public function offsetGet($offset) {
//fetch and cache $result
return $result[$offset];
}
/**
* @see ArrayAccess::offsetSet()
*
* @param offset $offset
* @param value $value
*/
public function offsetSet($offset, $value) {
}
/**
* @see ArrayAccess::offsetUnset()
*
* @param offset $offset
*/
public function offsetUnset($offset) {
}
Et c'est différent comment? Vous échangez simplement quatre méthodes magiques pour quatre autres méthodes magiques ...
@,ircaxell Les méthodes d'interface ne sont pas des méthodes magiques. Bien que je ne puisse pas ne pas sauvegarder avec des chiffres, je prétends que cela fonctionnera plus vite que de compter sur les intercepteurs
@Gordon: C'est plus lent, vérifiez le lien de la réponse ci-dessus. Et oui, alors que ce n'est pas une "méthode magique" dans le sens strict, il est magique dans le sens où l'interface permet une fonctionnalité de type magie (la possibilité d'utiliser des fonctions principales et des constructions de langue sur l'objet) ...
@ircaxell si vous le mettez de cette façon, alors oui, c'est un bon point.
J'ai fait des tests avec des méthodes de PHP Magic et des opérations de GET / SET NATITES (sur une propriété publique)
les résultats:
Les méthodes magiques sont beaucoup plus lentes que l'accès autochtone. Mais l'heure d'accès est toujours si petite, qu'elle ne fera pas une différence dans 99,9% de tous les cas.
Même si vous faites 1 million d'accès de méthodes magiques dans une demande, il ne prend toujours qu'environ 0,1 seconde ...
"lecture seule" signifie accès via des méthodes magiques.
l'image affiche les résultats PHP 5.5.9 et PHP 7.0.
Voici le script de référence:
https://github.com/stracker-phil/php- Benchmark / BLOB / MASTER / BENCHMARK.PHP
Dupliqué possible de __get / __ Set / __ Appelez les questions de performance avec PHP