Discussion :

[Watilin]

Bonjour !
C’est peut-être une idée à la con, mais je me demandais si, à l’avenir, on pourrait utiliser des branches de DOM pré compilées pour gagner en performance. Un peu comme les requêtes SQL préparées…
Ça serait utile dans les cas où on a besoin de créer en beaucoup d’exemplaires un même fragment DOM, avec simplement quelques variations, par exemple le contenu textuel.
Savez-vous s’il y a un projet de ce genre chez les « grands » navigateurs actuellement ?

[sekaijin]

non car l'impémentation interne du DOM est laissé libre seule l'API est normalisée.
la structure en mémoire d'un DOM GEKO, WebKit, IE, iCab, Opéra sont fondamentalement différents.
il ne sont donc pas portable

envisager de précompiler un segment DOM suppose que tous les navigateur sont capable de l'intégrer directement dans leur représentation mémoire donc que tous les navigateur partagent la même représentation.
ou alors que tous les navigateurs a avoir une procédure de transformation de ce DOM précompilé dans leur propre image mémoire.

la première approche implique qu'il n'y ait plus qu'un code DOM quelque soit la machine et le navigateur (bonjours la galère pour les machine bigindian si on choisit de faire un DOM commun dont la mémoire et géré en litleindian et vice versa) c'est donc la mort de tout les navigateurs au profit d'un seul. je ne pense pas que le monde soit prêt pour cela.

la deuxième enlève toute intérêt à la chose car interprété une sérialisation est tout aussi simple et rapide que de transformer une structure de donnée en une autre.

A+JYT

[Watilin]

Bonjour,
je vois ce que tu veux dire. Mais pourquoi justement, ne pas proposer une routine de précompilation dans l’API standard, qui serait implémentée de manière différente par chaque moteur ?
En fait je pense aux PDO de PHP qui permettent de faire des requêtes préparées avec la même syntaxe quel que soit le moteur de DB derrière (Oracle, MySQL, etc.).

Un exemple concret : j’ai un tableau décrivant les membres connectés sur un site, avec diverses colonnes dont le pseudo, la date d’inscription, etc. Chaque colonne est susceptible d’avoir un formatage différent, et donc un balisage relativement complexe.
Ce tableau est mis à jour par Ajax chaque fois qu’un membre se connecte. L’idée c’est de faire un peu comme .cloneNode(), mais avec un contenu #text différent, ce qui n’est actuellement, à ma connaissance, pas possible.

J’espère que c’est plus clair

[SpaceFrog]

là ou cela devient très complexe, c'est sur le true du clonenode car modifier juste une propriété mais tout de même cloner en profondeur ... c'est contradictoire. Ce ne serait pas facile de passer en paramètre la modification voulue ... en particulier si tu veux par exemple cloner un ul et n'en modifier que le texte du 3 eme li...
faut trouver un système de pointage sur le noeud
je pense qu'un truc comme les niveaux de parenthèses des regexp pourrait fonctionner, pointer sur le noeud avec un integer représentant l'ordre dans le flux du code html puis la propriété voulue

[sekaijin]

Bonjour,
je vois ce que tu veux dire. Mais pourquoi justement, ne pas proposer une routine de précompilation dans l’API standard, qui serait implémentée de manière différente par chaque moteur ?
En fait je pense aux PDO de PHP qui permettent de faire des requêtes préparées avec la même syntaxe quel que soit le moteur de DB derrière (Oracle, MySQL, etc.)...

Justement tous les moteur SQL proposent un mécanisme de requête préparé mais un requête préparé sur un moteur ne fonctionne pas sur l'autre

en fait les requête préparé n'ont en commun et encore que le SQL soit donc la forme textuelle comme peut l'être le HTML

A+JYT

[sekaijin]

non le principal problème c'est la représentation mémoire d'un segment précompilé

l'idée pour fonctionner devrait mettre en oeuvre un représentation mémoire universelle du segment dans celle-ci obligatoirement doit être représenté les types de base du DOM integer, float, string, char, boolean. aisni que les type complexe
document, nodeElement, nodeText, attibute, style ect.

quelle que soit la façon de représenter se éléments en mémoire pour passer de celle-ci à la représentation du moteur HTML cela nécessite une transformation plus ou moins lourde.

du coup un moteur HTML pour être compatible et efficace se doit d'avoir une représentation mémoire nécessitant le minimum de transformation ce qui implique au final une représentation unique dans tout les moteur et donc la mort de nombreux moteurs au bénéfice d'un seul.

si par conter on décide de ne pas avoir de représentation unique précompilé il n'y a plus aucune raison de précompiler le code HTML
en effet si on précompile de façon unique on peut envoyer au client un code précompiler et lui économiser du travail
si on précompile de façon différente pour chaque moteur alors c'est au client de le faire on lui envoie donc un source HTML
exactement comme lorsqu'on précompile pas.

il faut savoir que les moteurs HTML utilisent des cache de segment d'analyse de code (HTML CSS et JS) donc lorsqu'on refait appel au même segment (même source HTML) l'interprétation va beaucoup plus vite. l'intérêt de mettre du HTML précompilé devient tellement faible que le rapport coût gain implique de ne pas implémenter un mécanisme comme celui-ci.

c'est comme toujours la même question qui se pose.
si ajouter un fonction utiliser dans 1% des cas me fait gagner 50% de perf sur celle-ci mais me fait perdre 1% sur 80% des fonctions utilisé dans 90% des cas alors mieux vaut ne pas l'implémenter. le gain spécifique se fait au détriment des perf générales.

A+JYT

[Watilin]

Ah ça y est j’ai compris ce que tu comprends pas dans ce que je cherche à te faire comprendre
Bon, sous tout point de vue je crois qu’on est d’accord, mais je parle simplement d’une précompilation volatile, qui a la durée de vie de la page web. C’est pour ça que je faisais la comparaison avec cloneNode…
Et de toute façon, le SQL précompilé avec un PDO c’est pas portable non plus, si ?

[sekaijin]

c'est bien ce que je dis le précompilé côté client n'a pas d'intérêt car les interprètes utilisent des mécanismes de caches rendent la précompilation peut avantageuse. le gain est extrêmement minime et cela nécessite d'ajouter au coeur du moteur un mécanisme qui risque de ralentir le tout.

donc ajouter une fonction au coeur du moteur qui va ralentir même de façon minime 80 % des fonctions les plus utilisées est beaucoup trop coûteux en perf face au gain qu'on en retire
les mécanismes de caches eux sont utile à beaucoup plus de fonctions dans le moteur

le gain serait alors marginal et le coût élevés
je te laisse conclure

A+JYT


PS: oui les requête préparés ne sont pas portable