Comment les éditeurs gèrent-ils les documents de grande taille ?

Salut,

En voulant faire un petit éditeur avec numéros de ligne je me suis aperçu qu'au bout d'un certain nombre de ligne il y a un fort ralentissement (j'en ai discuté ici : Ralentissement important au bout de quelques lignes). Et pourtant ces lignes ne contiennent pas grand chose alors que les éditeurs gèrent des documents longs avec bien plus de balises dues notamment à la surbrillance syntaxique...

Je pense que cela devient lent lorsque la div éditable possède trop d'enfants... J'ai fait un test avec deux div éditables : une contenant le code entier et une autre dans laquelle on peut travailler sur seulement une partie du code eh bien là ça va vite, cela fonctionne normalement...

Du coup je pense que certains éditeurs ne travaillent que sur une portion du code à la fois mais l'utilisateur a l'impression de travailler sur tout le code.

On aurait donc le code entier dans une div à part ou dans des strings (ce qui éviterait de charger trop le DOM, je suppose aussi que travailler avec des strings est plus rapide et moins gourmand en mémoire ?) et seule une petite partie du code serait dans la zone éditable (cette partie dépendrait de la position de la srollbar).

Qu'en pensez-vous ?


------------------

Exemple d’éditeur : http://codepress.sourceforge.net - On voit bien qu'il devient lent quand le document devient important...

Salut,

Je reviens pour me répondre à moi-même...

Citation:

---

Envoyé par Beginner.

Du coup je pense que certains éditeurs ne travaillent que sur une portion du code à la fois mais l'utilisateur a l'impression de travailler sur tout le code.

On aurait donc le code entier dans une div à part ou dans des strings (ce qui éviterait de charger trop le DOM, je suppose aussi que travailler avec des strings est plus rapide et moins gourmand en mémoire ?) et seule une petite partie du code serait dans la zone éditable (cette partie dépendrait de la position de la srollbar).

---

Bon alors j'ai regardé plusieurs éditeurs "modernes" comme Ace, CodeMirror2, Orion... Et apparemment comme je le soupçonnais ils ne travaillent que sur une portion du code à la fois, c'est-à-dire seule une partie du code à la fois est injectée dans le DOM, le code entier étant stocké en mémoire (objet,tableau, strings...).

Du coup on doit gérer beaucoup plus de choses (comme par exemple afficher la bonne partie du code en fonction de la position de la scrollbar...), on ne peut plus utiliser certaines fonctionnalités toutes faites pour le DOM, il faut refaire l'équivalent pour la nouvelle structure en mémoire...

Et moi qui pensais me débrouiller avec une zone éditable ben c'est raté... Enfin ça marchait mais pour des document de petite tailles sinon ça devient trop lent comme expliqué dans l'autre fil...

...

Salut,

J'ai trouvé une confirmation de l’auteur de CodeMirror...
Apparemment CodeMirror1 mettait tout le code dans le DOM mais plus dans CodeMirror2 :

Citation:

---

Okay, reading that over, I feel I should actually market this more.

So:

* CodeMirror 2 deals with huge documents without trouble, because it
only puts the visible content in the DOM tree.

* Highlighting is now much, much faster because it doesn't directly
manipulate the DOM, and because the parser API is much less indirect.

* There is now an API for highlighting arbitrary pieces of text. The
highlighted text will deal well with being edited.

* There is also support for marking lines by putting stuff in the
line-number gutter.

* CodeMirror 2 support tabs. Supports them pretty well.

* The new API is much cleaner than the old one.

* The code is only 30k when put through UglifyJS. Take that, ACE.

---

Source : https://groups.google.com/forum/#!to...or/Wo6JQCSp9YA