JeuWeb - Crée ton jeu par navigateur
Conseil utilisation de classe - Version imprimable

+- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org)
+-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38)
+--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51)
+--- Sujet : Conseil utilisation de classe (/showthread.php?tid=4287)

Pages : 1 2 3 4 5


RE: Conseil utilisation de classe - guile - 25-08-2009

Pour le php je ne sais pas trop comment le script est interprêté.
En C par contre le nombre de ligne n'influe pas sur les performances, c'est son code compilé qui fait la différence, et dans ce cas, l'opérateur ternaire ?: est aussi efficace qu'un if then else, l'incrémentation (post- ou pré-) n'ont aucune différence.


RE: Conseil utilisation de classe - Anthor - 26-08-2009

Dans ce cas, un ptit APC, et plus de problèmes, l'OP-Code sera mis en cache Smile


RE: Conseil utilisation de classe - Argorate - 26-08-2009

Il semblerait que pour PHP, l'oppération ternaire soit plus lente que les if

http://www.magazine-jeux.com/Optimisation-du-code-2.html?var_recherche=optimisation


RE: Conseil utilisation de classe - Allwise - 26-08-2009

Ouais trop bien, on gagne 100 millisecondes si on se prive 500 000 fois de l'opérateur ternaire ! :good:
Ces optimisations font gagner des peccadilles... des cacahuètes... du vent...


RE: Conseil utilisation de classe - Sephi-Chan - 26-08-2009

Au vu de sa lisibilité, c'est pas forcément un mal. Surtout pour PHP. Confusediffle:


Sephi-Chan


RE: Conseil utilisation de classe - jo_link_noir - 26-08-2009

En même temps avec l'exemple c'est un peu normal que ça soit pas lisible :/
[code=php]$i<10000 ? $a = "1 ": $a = "0";[/php]

Perso je fait comme ça (j'évite quand même de le faire dans des exemples plus complexe)
[code=php]$a = ($i<10000) ? "1 " : "0";[/php]

Puis l'es vieux l'article, en php5 le ternaire est presque aussi rapide (plus ?), dommage qu'il n'y a pas marqué la version utilisé...
Tout façon c'est Anthor qui à raison ><


RE: Conseil utilisation de classe - Fnor - 27-08-2009

Citation :Test encore une fois étonnant, car il est le contraire de ce que j'obtenais en PHP4. La solution la plus rapide est donc l'opérateur ternaire bien que sa lisibilité soit absolument affreuse !

Source : http://www.vulgarisation-informatique.com/optimiser-php.php

Maintenant, je pense que son utilisation ne relève pas vraiment de l'optimisation, mais d'un choix personnel.

De mon côté, pour des petites conditions je l'utilise volontiers car elle ne prend qu'une ligne et est tout à fait lisible.

Quand ça se complexifie j'utilise le if/else...


RE: Conseil utilisation de classe - Sephi-Chan - 27-08-2009

Exact, quand c'est pour une petite affectation (genre la ligne ne dépasse pas 80 caractères), c'est pas mal. Mais quand ça s'étale, ça tue la lisibilité à cause du bruit que ça génère.

Cela dit, on dérive beaucoup. Pourquoi ne pas ouvrir un post sur la lisibilité (ce sera l'occasion de montrer un peu en quoi Ruby est génial Confusediffle: ) ?


Sephi-Chan


RE: Conseil utilisation de classe - Allwise - 27-08-2009

Ou un topic sur les "vraies" optimisations ce serait cool aussi. Ça pourrait faire gagner du temps à ceux qui cherchent à optimiser leur code, et ça mettrait surtout l'accent sur ce qu'il faut optimiser et ce qu'il faut laisser de côté.

La lisibilité c'est très subjectif de toute façon, et y en aura même qui diront que Ruby est indigeste comme tout :glace:

PS : Qu'est-ce qu'il se traîne le site aujourd'hui !


RE: Conseil utilisation de classe - Sephi-Chan - 27-08-2009

Je veux bien lancer le sujet sur les vraies optimisations, mais je ne suis pas sûr que celles de Ruby on Rails intéressent beaucoup de monde...

Cela dit, je ne suis pas d'accord sur la lisibilité des langages. Ruby a des possibilités que PHP n'a pas en ce qui concerne la méta programmation). À compétence égale, le code Ruby est forcément plus clair que du PHP (et plein d'autres) car le langage, sa syntaxe, ses possibilités, etc. est fait comme ça. PHP se rattrape sur d'autres points (la branche Ruby 1.8 est plus lente que PHP 5.3).


Sephi-Chan