Faudrait peut-être lire le message avant de répondre ? Ou même, te
renseigner sérieusement sur le sujet ?
Comme je le disais, je manque de temps en ce moment, alors je fais ce que je
peux pour apporter mes 2 cents, le soutien moral en fait parti, à defaut de
mieux ...
Ceci dit, j'ai adopter UPMCv2 puis 3 ... en y faisant des modifs, j'ai donc
pas mal mis le nez dans le code jusqu'à ces dernieres semaines ou j'ai du
decrocher par manque de disponibilité.
J'ai fait ce mail car je trouvai le ton un peu acide au vu du boulot fourni,
meme si tu es sans doute un des rares à pouvoir te le permettre ...
qu'est-ce que ca apporte ?
> On trouvera peut être des squelettes sur lesquels l'ancienne version est
> plus rapide(ce qui n'est même pas sur), mais forcement d'autre ou le
nouveau
> compilo a des perfs incomparables (cache du PHP notamment)
As-tu déjà mis le nez dans l'ancien compilateur avant de sortir
n'importe quoi ?
Non, et c'est ce que je disais (tu peux relire mon message ?)
Peux-tu me citer un cas *significatif* (pas juste dix
lignes de PHP séquentiel) où le nouveau compilateur cache des choses qui
n'étaient pas cachées dans l'ancien ?
N'importe quel traitement fait à partir de parametres specifiques passés en
GET ou en POST me semble-t-il.
Alors si le traitement est une usine à gaz, on gagne beaucoup, si il est
petit, on gagne un petit peu.
C'est à mon avis un gain enorme.
La possibilité d'abandonner les extras au profit de champs supplementaires,
indexables et requetables me semble egalement un apport fonctionnel avec des
implications importantes sur les perfs (surtout si on veut faire un tri ou
des filtres sur ces cirteres)
> Il me semble d'ailleurs qu'Emmanuel avait fait des tests qui appuyaient
ses
> dires mais le mode opératoire étant critiquable,
Je n'ai toujours pas lu un argument crédible pour expliquer en quoi le
mode opératoire était critiquable (encore moins une proposition d'un
*autre* mode opératoire). D'ailleurs Emmanuel ne le trouvait pas
critiquable au début, lorsqu'il montrait un gain en performances pour
son compilateur. Je suis bien placé pour le savoir : c'est moi qui l'ai
aidé à réaliser les mesures en question.
Alors voilà il y a trois solutions pour mesurer les performances :
- ce que je fais : utiliser un bench HTTP (type ApacheBench, mais il y
en a d'autres)
- utiliser des "microtime" dans le code PHP (mais le problème est qu'on
oublie les temps de parsing des fichiers inclus en premier lieu)
- lancer le truc en ligne de commande (si c'est possible), style "time
php -q"
La quatrième solution c'est de ne rien mesurer et de prétexter des gains
en performances basés sur des arguments fallacieux.
Je n'ai pas tout suivi de ce coté la non plus, l'important reste à mes yeux
qu'il n'y ait pas de baisse de perf, et les simples tests de debuggage ne
semble pas en faire ressortir.
Ceci dit, les seuls tests non critiquable que j'ai rencontré jusqu'ici ont
été fait par Sun pour un client pour evaluer des environnement J2EE, je n'ai
pas vu la facture, mais ca a pris une semaine à quelques pointures pour y
arriver et ils disposaient d'une belle plateforme bien isolées et des
ressources suffisantes pour que le "coté client" n'entre pas en compte.
Personnellement j'utilise OpenSTA qui a l'avantage de pouvoir observer
séparement les differents processus et de mesurer le temps de reponse
effectif pour N sessions en jouant des scenari en paralelle.
Le probleme est vraiment d'isoler le systeme et de disposer de suffisement
de ressources machine et reseau pour jouer les tests.
> 4) concernant la lisibilité du code, je regarde SPIP depuis quelques
mois et
> tout cela s'améliore à chaque version,
Moi je développe SPIP depuis trois ans, et je confirme que cela
s'améliore à chaque version. Cependant je ne parle pas du code en
général, je parle du compilateur. Merci de rester dans le sujet.
La propeté du code me semble quelque chose de tres relatif ... il faut donc
bien se referer à quelque chose non ?
> Les dernières semaines ont été très riches en refontes et modifications
et
> tout le monde sait que ça n'est pas en phase de debug et dans le speed
qu'on
> produit du beau code commenté.
Le code en question est tranquillement développé en interne par Emmanuel
depuis neuf mois, que viennent faire les phases de speed et de debug
là-dedans ?
Il me semble pourtant qu'il y a eu pas mal de changement recemment, mais je
parle de l'ensemble des fichiers de la contrib, peut etre parles-tu d'un
fichier en particulier, mais tu n'etais pas tres precis ...
> reste à bien nettoyer et commenter le code,
C'est exactement ce que je disais. Tu as lu mon message ?
Et toi tu as lu le mien ?
Faut arreter la parano !
Je dis juste que le code est un peu jeune et mouvementé pour pouvoir exiger
la qualité immediate, c'est tout.
> ça
> me parait assez logique d'attendre que le code soit stabilisé pour faire
ce
> travail
C'est bizarre, moi j'ai plutôt tendance à penser qu'il est beaucoup plus
sain de faire du code propre le plus tôt possible, et que le salir
volontairement pour cause de micro-optimisations doit être 1) remis au
plus tard possible 2) dûment prouvé par des mesures de performances.
Je te laisse choisir laquelle des méthodologies est la plus viable.
Je parle des commentaires et de l'indentation, pas des modif, je ne me
permettrait pas de juger de l'efficacité d'un bout de code, sauf si j'ai
mieux à proposer.
> (qui pourrait d'ailleurs être fait par qqun d'autre qu'Emmanuel qui
> a déjà bien donné je pense).
Et les autres développeurs de SPIP, ils ont pas assez donné ? Si on
t'avait livré un SPIP codé à la porc sous prétexte qu'on a déjà assez
travaillé et que tu n'as qu'à nettoyer le code toi-même, tu dirais quoi
?
Ca depend ce que tu appelles "codé à la porc"...
Mais une chose est sure, je ne serai pas venu gueuler sur la liste que
c'etait mal codé, et si je l'avais fait, tu m'aurais envoyé chier et tu
aurais eu raison.
Est-ce que le code doit etre propre et bien commenté pour avoir le droit
d'atterir sur la beta du CVS ?
Le plus possible, OK, mais une fois la machine lancée, il faut gerer les
urgences.
Il a fallu du temps à Spip pour arriver au niveau de qualité actuel, je
pense qu'on peut laisser un peu de temps à ce nouveau compilo avant de
s'enerver, non ?
Le développement collaboratif ce n'est pas la taylorisation du travail
intellectuel, il n'y a pas un gars qui écrit le code et un autre qui
corrige les fautes d'orthographe derrière. Et surtout, quand on arrive
dans un projet existant, on s'adapte aux conventions établies.
Je ne connais pas les echanges que vous avez eu avant de decider de
l'integration, mais on ne peut pas dire que ce genre d'information soit bien
formalisée quelque part ... ou alors je ne les ai pas trouvé
C'est à mon avis un manque car cette norme n'est du coup pas discutable et
soumise à interpretation (genre si si, j'ai trouvé une fonction nommée comme
ca)
> et en général, je dis pas "c'est nul" (ce
> qui ne fait pas beaucoup progresser le "nul" en question et a plutôt
> tendance à dégrader encore un peu la qualité de son travail, pour lequel
il
> est pourtant payé), je dis plutôt "tu devrais faire comme ça"
Oui, moi aussi. Seulement la première fois tu expliques gentiment, et
les fois suivantes tu deviens un peu plus laconique, c'est naturel non ?
Oui, mais ces echanges n'ont pas eu lieu sur cette liste me semble-t-il...
Emmanuel sait très bien ce qu'il faut faire, il faut principalement :
- éviter les expressions de vingt lignes de long, et autres
constructions illisibles
- nommer les variables et fonctions de façon cohérente avec le reste de
SPIP
- utiliser des tabulations pour l'indentation (une indentation == une
tabulation)
Ben voila qui est plus clair !
-Pour les expressions, il me semble qu'il est un peu tard ou qu'il n'y a pas
urgence.
Le debug a l'air de toucher à sa fin, et je pense qu'Emmanuel connait son
code.
Apres, evidement, c'est necessaire pour que ce code puisse etre maintenu,
mais c'est un bon moyen de s'approprier du code, je trouverai donc judicieux
que cela soit fait par qqun d'autre.
- Pour le nommage des fonctions, ca me parait urgent, il faudrait donc
lister ce qui ne convient pas et proposer de nouveaux nommage, ca serit sans
doute plus constructif et chacun pourra defendre objectivement ses opinions.
Les modifications sont ceci dit assez facile à faire (refactoring ou
rechercher remplacer)
- Pour l'indentation, je comprend mieux l'agacement, mais il y a des outils
qui font ca tres bien, c'est quand meme pas si grave ...
> et faisons aboutir rapidement ce boulot
> d'intégration qui s'est déjà plié, me semble-t-il, à toutes les
contraintes
> posées par Spip (compatibilité ascendante, versions de PHP et de MySQL,
pas
> de POO, respect des exceptions de fonctionnement ...)
Le "pas de POO" n'a jamais été une contrainte de SPIP. Par contre, "pas
de POO dispendieuse et inutile", c'est préférable.
Nous sommes d'accord la dessus et je crois que le dernier rappel des
arguments etait convainquant.
Ca n'etait vraiment pas une critique.
Pour la version de PHP, vu le nombre de foreach que j'ai vu passer ça ne
peut de toute façon pas être compatible PHP3, et côté MySQL certaines
constructions font/faisaient intervenir des sous-requêtes (MySQL > 4.1).
Ce n'est pas forcément un problème redoutable, mais je ne dirais pas que
ces contraintes ont été scrupuleusement respectées...
Je n'ai pas regardé les dernieres versions , mais il me semble que les sous
requetes avaient été ecartées au maximum
Quant à PHP3, je croyais que la decision avait été prise d'abandonner la
compatibilité pour la 1.8 avant l'annonce de l'integration du compilo, mais
je me plante peut etre ...
Pour ce qui est de la compatibilité ascendante, on a frisé la
catastrophe ({doublons} qui change totalement de sémantique). <INCLURE>
a semble-t-il un peu changé mais cela reste mineur.
Ca a été reparer en un temps record, ce qui renforce encore l'idée que ce
code est maintenable
Quant aux conventions de codage (nommage des variables, indentation du
code, lisibilité, tout ça), le moins qu'on puisse dire est qu'elles ne
sont pas du tout respectées.
Et mon problème à moi c'est que la synchronisation avec spip-lab
implique de backporter les nouveautés importantes (dans un sens comme
dans l'autre) quand elles sont terminées. Or moi je ne peux pas
backporter un code aussi incohérent avec le reste des conventions de
style et de lisibilité ; et je ne jouerai pas le nettoyeur de service.
S'il n'y a pas de backport, les deux branches deviennent incompatibles
et c'est la merde. Tu comprends ?
Oui beaucoup mieux, mais je pense que le probleme pouvait etre posé
autrement (et je ne suis pas sur que ca soit le seul probleme ...).
Tu pourrais par exemple nous lister les fichiers problematiques et nous dire
ce qu'il faudrait faire pour qu'ils te conviennent, chacun pourra alors
faire un petit bout de nettoyage dans les semaines à venir et tout pourra
rentrer dans l'ordre sans enervement inutile.
Si Spip est bien une communauté comme je le crois, il me semble qu'il faut
permettre à tout le monde de s'impliquer.
Dans cette affaire, tout le monde a découvert du jour au lendemain que
l'integration commencait, sans vraiment avoir les elements, sans connaitre
les raisons du choix, les points de friction ...
beaucoup de discussions ont eu lieu entre vous en amont, nous ne savons pas
tout, ce n'est quand meme pas toi qui va nous le reprocher ???
Je trouve que l'implication generale des derniers jour montre à quel point
le choix est bon, alors maintenant, avancons de facon constructive.
@++
