Reprise du message précédent :

 
performance
Et pour les mots bah tu sais ce que ça veut dire BDD, Array et Switch donc tu devrais tout comprendre non ?  

La problématique se pose en fonction de comment tu veux positionner le texte par rapport au background et quel type de background c'est.

Premature optimisation is at the root of all evil, fait gaffe.

En l'occurence avec un si petit volume de données, ça ressemble bcp à de la micro-optimisation.

Je vois mal le rapport entre une BDD et une structure switch.

 
Bah en gros tu peux avoir :  
 
- une table avec 1000 entrées, dans laquelle tu vas chercher un élément
- idem mais avec un Array
- un switch avec 1000 case et 1000 $titre $contenu
 
C'est les 3 possibilités qui me sont venues à l'esprit

Tu peux gagner facile 3 ns et 5kB de RAM avec le switch

Après si tu veux faire un travail professionnel => BDD.

Et *si* un jour t'as des problèmes de perfs, fout un cache serveur et gagne 80% de temps d'execution.

 
C'est bien ce que je dis.
Comment tu fais donc ?

http://diveintohtml5.org/everything.html
 
Win.

 
Pourquoi la BDD serait forcément un travail professionnel pour un contenu statique ?
T'as pas l'impression que c'est une sorte de réflexe de nos jours de tout mettre en BDD ?

 
Bah je peux pas te répondre si t'es pas plus précis dans la question  
Car dans certains cas, ça pose aucun problème. Si ton background est une image à taille fixe à centrer au milieu, padding ou pas ça change rien. Si ton background est à commencer dès le bord du bloc padding compris, ça change rien, etc. Donc si tu précises pas les paramètres du contexte je peux pas répondre à ta question

[

WTF?
Pour du contenu statique tu fais du php avec base de données? Ah ben bravo...

J'ai du mal à croire qu'une liste de 1000 éléments du même type puisse s'appeler un contenu "statique".

Et non c'est pas un réflexe, juste un outil adapté (*base* de *données*)

Mais c'est sûr qu'avec aussi peu de détails précis de ta part on peut débattre longtemps.

Bah c'est justement ma question en terme de performance...

En terme de performances le mieux c'est les fichiers HTML statiques, sans PHP...

 
non mais OSEF c'est statique c'est tout 1000 noms de villes par exemple, ça risque pas de bouger. Bref, c'est statique.
Donc ?

 
A ce niveau là les perfs c'est de la branlette...

@Alekusu2 : T'es quand même marrant, tu viens demander des conseils et tu ne prends absolument pas en compte ce qu'on te dit...
Tu veux qu'on te répondes ce que tu as envie d'entendre quoi.

Franchement si c'est ça, vaut mieux que tu ailles sur Developpez.com, tu t'amélioreras jamais mais au moins ils répondrons à tes (mauvaises) questions.

oui mais bon imaginons qu'on puisse pas faire de HTML statique, quel est le mieux ?
 
Si on part sur un switch, la personne doit charger tout le fichier PHP qui contient les 1000 éléments pour juste avoir les infos d'un seul élément, alors que si c'est du BDD SQL on se connecte pour prendre les infos d'une seule, au niveau des performances, quel est le mieux ?
 
D'ailleurs si une personne charge un fichier PHP qui contient les 1000 éléments, le cache va mémoriser l'ensemble du fichier PHP ou bien uniquement ce qui a été balancé au client ?

 
Je viens demander des conseils et j'explique de manière claire, et on me demande de tout justifier, si je dis que le contenu est statique pas obligé de débattre sur "est-ce que c'est vraiment statique" Je sais plus qui avait dit que sur ce topic faut toujours se justifier pendant 2 pages pour avoir une réponse

 
Et si c'est une page qui se charge 1000 fois par seconde est-ce que la différence est toujours négligeable ?

Cf Developpez.com .

C'est comme si j'allais voir un expert en fabrication de vélos et que je lui demandais "c'est quoi le mieux comme matériau pour un vélo niveau poids, le carton ou le PVC ?". Et qu'en plus  de ça, je le prenais de haut parce qu'il me demande de justifier ma question.

Qu'est-ce que tu veux qu'on te dises.

Cache serveur dans ce cas.

 
Sauf que c'est pas la première fois que tu viens demander des conseils et jamais tu ne les prends en compte
 

 
Si t'arrives à avoir 1000 affichages par seconde, bravo, il y a de fortes chances que tu fasses fortunes
Sinon ton contenu statique tu peux aussi le gérer comme tel, en statique

 
Je demande si pour un contenu STATIQUE simple qui est une liste d'éléments qui se comptent en milliers d'éléments et pour laquelle on affiche à chaque fois qu'un élément (qui par exemple doit se charger 1000 fois par seconde, cf ma réponse à koskoz), il faut mieux de la BDD, du switch ou du array, en terme de PERFORMACE. Pourquoi c'est impossible à répondre ?
 

 
Ah bon ? Par exemple quels sont les conseils que je n'ai pas appliqué dans mon code ensuite ?
 
 

 
Et donc entre naviguer dans un Array ou un switch, quel est le plus performant ?
 

 
Et donc avant le cache, la diff de perf entre les 3 est totalement négligeable ?

Je t'ai déja répondu, c'est sûrement le switch. Mais ne fait jamais ça.

huh ? Tu me conseilles le switch mais je dois jamais le faire ?  

 
Le fait de faire flotter tous tes blocs par exemple.
Enfin bref, j'arrête ici.

Je ne te le conseille pas du tout, je répond juste à ta question très fermée

Le fait de faire flotter tous les blocs, on a eu un débat ici et ça a fini par dire "aucune technique n'est meilleure qu'une autre", donc je vois pas pourquoi tu reviens dessus Et de plus j'ai clairement jamais demandé de conseils sur ça, c'était juste un débat auquel j'ai participé, ce qui n'a rien à voir avec la question clairement que je pose ici et où je ferai ce qu'on me conseille de faire.
De plus, tu n'es pas dans mes pages HTML pour savoir si je mets en pratique les conseils ou pas, ou même savoir si ça peut faire évoluer certaines de mes pratiques ou me faire poser des questions, c'est donc bien présomptueux

Mais pourquoi tu dis de jamais le faire, quel pourrait être les problèmes d'une telle technique pour que tu le déconseilles ?  

C'est illisible, inmaintenable, pas standard, pas évolutif, et ça n'a aucun avantage, même pas les perfs puisque un cache serveur serait 100x plus efficace.

 
Dans ce cas pourquoi tu conseilles pas de mettre en BDD voire Array si c'est mieux en terme de perf ?
(et j'ai pas compris le "pas standard" )

Parce que ta question ne posait pas l'hypothèse d'un cache serveur, et que sans cache serveur, la BDD est moins performante

Pas standard = pratique inhabituelle donc dure à appréhender, pas fait pour. Le standard (de fait) c'est d'utiliser des outils adaptés, comme une BDD.

 
Merci
Et entre un Array et un switch, y a une différence de perf ou c'est absolument pareil ?

Ca charge l'array en mémoire, donc si t'as un Thomson TO7 de 1982 comme serveur ça peut être notable.

 
   
 
Bon bah ça ira alors
 
Merci beaucoup

Alekusu , t'as un background informatique ou quelquechose ?
Tes questions sont étranges .. on dirait que tu veux apprendre un manier un une Ferrari sans savoir conduire une Punto.

Une idée pour que le plugin quicktime détecte tout seul width/height d'une vidéo?

Parce qu'en pratique c'est ultra chiant d'avoir à manuellement indiquer ces valeurs pour chaque vidéo. Et avec le embed seul, il crop à 320x240    
 
Avec html5 tout était sensé être rose, mais comme chaque navigateur ne supporte pas les mêmes codecs, rien ne va plus.

une idée pourquoi tu utilises une video en quicktime. si c'est pour faire fuir tes utilisateurs et les empecher de voir ta video, tu as tout gagné.
tu réencode la video en flv et basta

Non je ne veux plus voir de Flash. Cette saleté est trop lente et en plus il faut se prendre la tête avec width/height qui est ultra pénible comme je l'ai déjà dit!
 
Apple a raison. Mater une minable vidéo sur youtube en flash met à genou mon mac, alors que regarder un movie trailer encodé en bonne qualité sur le site d'apple (quicktime donc) y'a aucun souci. Mais sinon oui quicktime fin 90, début des années 2000 c'était la plaie, et RealPlayer c'était encore pire.
 
J'offre également du Theora pour l'html5 de FF3.6 mais c'est pénible à gérer, il faut réencoder, etc.
 
J'aimerai bien n'avoir qu'un seul fichier h.264/mp4 et que tout le monde soit content.