Salut,
On a trouvé un cas pathologique sur prison.eu.org, sur lequel
le fait d'échapper tous les tags HTML a tendance à faire
exploser les temps de calcul (multipliés par dix). En fait
le problème est lié à des textes plutôt gros contenant
beaucoup de tags HTML (copiés / collés en général).
Du coup j'ai désactivé cet échappement, mais il faut désactiver
en même temps les apostrophes "typographiques"... Est-ce
vraiment gênant ?
a+
Antoine.
Du coup j'ai désactivé cet échappement, mais il faut désactiver
en même temps les apostrophes "typographiques"... Est-ce
vraiment gênant ?
En fait ces apostrophes sont assez jolies, il faudrait trouver une astuce
pour les calculer vite ; la première tentative a échoué, certes ; mais...
Une boucle avec des strpos('<'....) devrait aller assez vite, non ?
-- Fil
Si on peut trouver un moyen, je tiens vraiment à ces apostrophes typo: obtenir une belle typographie (aussi belle que possible, en tout cas), c'est un des critÚres premiers de SPIP. Et l'apostrophe typographique, de ce cÎté, c'est un gros progrÚs.
=> Je ne peux pas essayer moi-même sur prison.eu.org, mais que se passe-t- il si l'on n'échappe que les codes HTML qui contiennent le symbole apostrophe? A priori, s'ils font des copier-coller depuis un logiciel de mise en forme, les codes contiendront plutÎt des guillemets, non?, donc peu de choses passées en échappement (avec les variables passées dans des guillemets, et non dans des apostrophes comme on fait en PHP).
A*
Si on peut trouver un moyen, je tiens vraiment à ces apostrophes typo:
obtenir une belle typographie (aussi belle que possible, en tout cas),
c'est un des critères premiers de SPIP. Et l'apostrophe typographique, de
ce côté, c'est un gros progrès.
A moins de mettre le texte en polices énormes, seuls ceux qui
savent qu'il y a un changement sur l'apostrophe remarqueront
effectivement l'amélioration. En lecture normale, on ne remarque
absolument rien. C'est microcospique et quasi-dérisoire.
=> Je ne peux pas essayer moi-même sur prison.eu.org, mais que se passe-t-
il si l'on n'échappe que les codes HTML qui contiennent le symbole
apostrophe? A priori, s'ils font des copier-coller depuis un logiciel de
mise en forme, les codes contiendront plutôt des guillemets, non?, donc peu
de choses passées en échappement (avec les variables passées dans des
guillemets, et non dans des apostrophes comme on fait en PHP).
Le problème est que ça devient totalement imprévisible : imagine
quelqu'un qui met du HTML dans ses articles, et dont seul certains
tags se voient ajouter des espaces insécables (ceux qui n'ont
pas d'apostrophes).
Et puis on ne peut pas prévoir à l'avance les cas pathologiques
(beaucoup de tags avec des apostrophes).
@ Arno* <arno@scarabee.com> :
Si on peut trouver un moyen, je tiens vraiment à ces apostrophes typo:
obtenir une belle typographie (aussi belle que possible, en tout cas),
c'est un des critères premiers de SPIP. Et l'apostrophe typographique, de
ce côté, c'est un gros progrès.
Je suis d'accord
=> Je ne peux pas essayer moi-même sur prison.eu.org, mais que se passe-t-
il si l'on n'échappe que les codes HTML qui contiennent le symbole
apostrophe?
Avec $regexp_echap = "<(a|[^>]*')[^>]+>"; le temps de calcul est
identique à celui qu'on a maintenant : je pense que c'est bon, du coup.
Et, sur le même texte litigieux, on gagne encore pas mal de temps (10%-20%)
si on fait
$regexp_echap = "<(a|[^>]*')[^>]+>"; // Echappement tout HTML
while (preg_match('/'.$regexp_echap.'/i', $letexte, $regs)) {
(au lieu de eregi()...). Ce qui milite pour le passage complet à preg dès
que possible....
-- Fil
@ Arno* <arno@scarabee.com> :
> Si on peut trouver un moyen, je tiens vraiment à ces apostrophes typo:
> obtenir une belle typographie (aussi belle que possible, en tout cas),
> c'est un des critères premiers de SPIP. Et l'apostrophe typographique, de
> ce côté, c'est un gros progrès.Je suis d'accord
Etant donné que les pages sont en cache, ça n'est qu'au recalcul que c'est
si long, non ? Est-ce vraiment un problème dans ce cas ?
Pour moi, ce genre d'apostrophe est un des trucs qu'on voit pas forcement,
mais qui fait beaucoup pour rendre un texte joli... Subliminal est un bon
mot ? 
(en passant, comme en musique avec des instruments qu'on entend
pas forcement, mais qui ajoutent beaucoup
> => Je ne peux pas essayer moi-même sur prison.eu.org, mais que se passe-t-
> il si l'on n'échappe que les codes HTML qui contiennent le symbole
> apostrophe?Avec $regexp_echap = "<(a|[^>]*')[^>]+>"; le temps de calcul est
identique à celui qu'on a maintenant : je pense que c'est bon, du coup.Et, sur le même texte litigieux, on gagne encore pas mal de temps (10%-20%)
si on fait$regexp_echap = "<(a|[^>]*')[^>]+>"; // Echappement tout HTML
while (preg_match('/'.$regexp_echap.'/i', $letexte, $regs)) {(au lieu de eregi()...). Ce qui milite pour le passage complet à preg dès
que possible....
Ce qui est possible de faire aussi, c'est d'utiliser un preg_match tout
con dans le while (genre preg_match("/<.*>/") ), et de faire directement
un preg_replace à l'interieur. Dans un script perl de parsing, une astuce
de ce type avait tout de même rendu le script 8 fois plus rapide
Comment peut-on voir le code courant, il y a un viewcvs/lxr quelque part ?
(on peut me pointer vers une page de spip.net, mais je trouve pas...
Etant donné que les pages sont en cache, ça n'est qu'au recalcul que c'est
si long, non ? Est-ce vraiment un problème dans ce cas ?
Oui, si le recalcul part en timeout, ça se produit à chaque fois que la page
est appelée.... puisqu'elle n'est jamais calculée entièrement ;(
Ce qui est possible de faire aussi, c'est d'utiliser un preg_match tout
con dans le while (genre preg_match("/<.*>/") ), et de faire directement
un preg_replace à l'interieur. Dans un script perl de parsing, une astuce
de ce type avait tout de même rendu le script 8 fois plus rapide
Oui, ça serait pas mal ; sauf qu'on veut garder un fonctionnement sous php3
sans preg, tant que possible (mais dans les endroits critiques on peut
dédoubler le code).
Peux-tu détailler le patch que tu proposes ?
Comment peut-on voir le code courant, il y a un viewcvs/lxr quelque part ?
(on peut me pointer vers une page de spip.net, mais je trouve pas...
Tu regardes le pied de page de chaque mail circulant sur cette liste, et tu
auras la réponse. 8^)
-- Fil
apres une heure de grattgratt, je peux proposer plusieurs choses 
1 - une autre regexp
ton principal ajout est, selon moi, la presence de l'apostrophe, donc
pourquoi pas simplement :
$regexp_echap = "<([^>]+')[^>]+>";
Et puis un ereg au lieu d'un eregi aussi
ah et comme tu n'utilises que $regs[0], les parentheses sont ptetre
inutiles également :
$regexp_echap = "<[^>]+'[^>]+>";
Hey, c'est presque lisible ! 
2 - Bon, ce que je disais quand je racontais ma vie, je pense pas que ca
accelere beaucoup ici (et ça m'a pas l'air evident à implementer à vrai
dire)
Le truc etait d'utiliser une regexp plus courte telle que "<[^>]+>", et de
faire quelque chose comme :
Tant que cette regexp courte match
si la regexp longue match
faire le remplacement
fin si
fin tant que
Le probleme ici est que SPIP peut faire plusieurs remplacements par ligne
(donc la courte pourra continuer a matcher meme si la longue matche plus
-> boucle infinie)
Ca necessite de garder un compteur, tel que voir si $num_echap a changé ou
pas. Le fait est que je ne suis pas sûr que ça apporte grand chose sur ce
bout de code, vu que la regexp est pas si compliquée au final... Mais sur
des regexp plus compliquées ca peut valoir le coup (celle des images et
documents ?).
Vala vala