Reprise du message précédent :
Bah non justement
Quand t'as un str_replace avec  100 smilies et du bbcode, c'est assez long

  Vous me faites rire. Doit bien y avoir 1000 affichage pour 1 insertion ou edition dans un forum . Alors je vois pas pourquoi on s'ocuperai de tout remplacer lors d'un affichage plutot que "seulement" lors d'une insertion.

J'ai 800 smileys et un paquet de bbcode puisque je me sers du BBcode pour mettre en page les articles sur le site de ma femme, je me sers donc de la même routine de traitement à l'affichage pour toutes les données bdd du site de ma femme et quand je remplace mon routine_aff_texte($txt) par un simple echo $txt, la différence est ridicule.    

Ha oui et autre chose, on parle de remplacer les smileys par des <img src dans la bdd, mais perso, mon bbcode traite aussi le Flash par exemple, tu vois pas la masse d'info que ça ferait en plus.

Avec un str_replace ($motif,$remplacemen) où $motif et $remplacement sont des array a 800 entrées?

le mieux serait de faire 2 cases "messages_brut" et "message_html" dans la table, comme ca quand on edit, on prend le message brut, on modifie et on met à jour les deux cases ensuites.
 
Bon c'est clair que ca double la taille de la bdd, mais la vitesse est inversement proportionelle à la taille.

Vi.

 
He bien plutôt que de polémiquer, benche un coup, tu verras qu'il n'y a quasiment aucune différence à remplacer à la volée.
 
Peut être qu'au niveau de tes perfs sur ton systeme tu n'y vois pas de différences, mais tu te compliques grandement la vie pour l'édition (et surement d'autres choses).
 
Tout ça pour gagner des ms à l'affichage qui sont inexistantes ca se compte en µs

Imagine que pour les quotes, tu veuilles complètement changer la façon de les afficher. Genre passer d'une <TABLE> à un <DIV> ou inversement ou rajouter une <TR>.
Tu vas bien t'amuser à faire la conversion de tous les messages dans ta BD.
 
 

Si on prend l'exemple du qui prend 52 octets chez moi une fois passé en HTML, et si l'on considère qu'i ly a en moyenne 2 smileys par message.
Ca fait quand même 100 octets de plus par message.
Sur un forum même modeste, on arrive assez vite à ne serait-ce que 100 000 messages et ça fait féjà 10 Mo de bouffés rien que pour des smileys (à supposer que c'est 1 octet par caractère ce qui n'est même pas forcément le cas)

il faut préciser que c'est uniquement quand MySQL est configuré pour des jeux de caractères "exotiques"

parce que c'est les disques qui limite sur un forum, pas le CPU

non

qui peut le plus peut le moins
 

taille des données cher ami

et la tu tues completement les perfs de ton forum

J'ai fait le test.
Un simple  
 
$texte= blabla[...] qqs smilies
echo $texte
Ca mets 2.2secondes pour 1000 affichages.
 
En revanche, quand je fais  
 
$texte= (le meme qu'en haut sans que les images sont remplacées par le code du smilie)
$contenu=nl2br(mysql_real_escape_string(htmlentities($texte))) ;
      $motif =....
      $remplacement =....
   
      $contenu = str_replace($motif, $remplacement, $contenu);
echo $contenu;
Ca met 10.5 secondes
C'est 5 fois plus lent

 
On peut voir le code pour tes bench?

Bah c'est ca , dans une boucle for. Avec en haut le microtime et en bas l'affichage du microtime (en dehors de la boucle bien sur)

Il vient faire quoi là, le mysql_real_escape_string ? c'est pas pour faire des requetes SQL ? parce que là, j'en vois pas l'interet
 
Et pour tes tests, tu as pris en compte le rapatriement des données auprès du serveur SQL ? car d'après ce que j'ai lu sur ce topic, le passage -> Mysql -> PHP, c'est long

C'est ce que je m'amusais à faire au debut. Mais ca manque de souplesse. Tout est figé.

1. je vois pas ce que le mysql_real_escape_string vient foutre ici, ça sert à injecter des données dans la BDD
2. ce test a à peu près autant de valeur que les tests de doubles quotes versus simples quotes (whoa on gagne 20% sur les simples quotes . Pas de bol ce n'est pas la partie qui ralentit le forum (le bottleneck). Tu est heureux parce que tu as gagné 80% sur 1% du temps de génération de tes pages, donc tu es heureux d'avoir gagné 0.8% sur la vitesse de génération de tes pages. Super .

Ouai y'a pas de mysql_real_escape string c'etait une erreur
 
Bah je rapatrie pas les données dans les deux benchs, ca revient au meme

non, car plus tu as de données, plus c'est long, donc si tu fais tes replaces après le rapatriement, tu ramene moins de données donc le temps que tu 'perds' tu peux le gagner ici. Et Ce temps de rapatriement peut être un goulot d'etrenglement alors que les replaces, bah, bof quoi...

Bof, j'suis pas sur le gain soit justifié. La election a faire est peut etre un peu plus grosse, mais c'est pas 2 fois plus gros non plus

pourquoi ca tue les perfs ?

T'as 2 fois plus de données et 2 fois plus d'ajout insertion à faire

oui mais ca ne veut rien dire, je te parle de disque dur là

rajout d'un champ text supplémentaire dans la db, et deux fois plus de donnée.
Il ne faut pas oublier qu'à l'heure actuelle au niveau web le bottleneck c'est les disques, pas le CPU.

Y'a plus de données à selectionner ouai. Mais ca vaut le coup?  
SI on selectionne un post plus gros, c'est vraiment plus lent?

tu veux dire "supplementaire dans la table" ? parce que si je créé une table à part "message_brut" que l'on consulte seulement lors d'un edit, ca ne devrait pas changer les perfs lors de la lecture et l'ameliorer puisque qu'il ne faut plus parser.
 
en résume:
 
lors d'un edit: on selectionne le message dans la table "message_brut"
lors de la mise a jour: update de la table "message_brut" et de la table "message".
 
Et puis pour l'espace, le prix du Go ne coute plus grande chose de nos jours.

Trop bien, la jointure supplémentaire et les 2 update au lieu d'un à chaque edit...

oui mais la table message sera toujours plus grosse que sans parsing

tu crois que parser 40 messages par page vue c'est mieux ?    

ben quand on voit la taille de hfr, on se dit que la place n'as pas trop d'importance avec des millions de messages, non ?
ca a l'air de tourner aussi vite qu'un forum avec des milliers de messages.

La place occupée est une fausse excuse car ceux qui ont une BDD de 1 Go par exemple ne sont pas légion car ça représente 1 à 2 millions de messages, faut déjà les sortir. Or quand on en arrive là, on a généralement son serveur dédié et un "gros" site avec un peu de moyen, donc avoir 40 Go d'espace libre c'est pipo à avoir (sans parler perfs, raid, toussa) et on est tranquille pour 10 ans et plus avant de les remplir. Tous les forums ne sont pas Hfr en taille... Chaque méthode a ses avantages et ses inconvénients (soit on parse tout à gogo pour chaque affichage, soit on rappelle uniquement les data déjà formattées sans s'embêter).

Ah enfin un partisan de la méthode "j'fais pas forcement comme joce parce-que mon forum n'aura  pas des milliards de mesages"

Mais c'est quand même contradictoire votre point de vue...
Vous dites :
"Moi sur mon forum y'a presque personne, presque aucun message, alors je vais compliquer mon code et risquer de faire face à de grosses emmerdes en cas de changement de la façon dont j'afficherai les messages"... tout ça pour gagner quelques millièmes de seconde alors que votre hypothèse de départ est : "le forum est peu fréquenté" et que donc y'a pas vraiment besoin de grappiller ce temps.

tiens j'ai une question, pour mon interface de réponse j'ai pris tinymce (ca m'a semblé etre le mieu, compatible ff en plus) mais je me demandait comment faire une option pour éditer tres rapidement son message comme sur les forums ipb?
 
je trouve que cette feature est assez intéressante mais je pige pas trop comment ca marche

je ne sais pas comment fonctione ipb, mais ca doit etre du ajax d'aprés ta description.
 
Tu peux expliquer le fonctionnement  de cet fonction ?
 

en faite sur ton post tu a un lien "edition rapide" et si tu clique tu peux directement éditer ton post dans la page même du topic et tu a un autre menu javascript je crois avec "terminer l'edit ou annuler"  
 
en clair c'est ca :  
 

ha ben c'est du js qui remplace le contenu du message par un formulaire, c'est tout simple. Le text en ubb code doit etre recuperer grace a ajax ou un truc du genre.