Speed-Trimmen von parseneu

[gaenseklein]

mit einführung der sidebar wird offensichtlich, dass der editor zu langsam wird. hier eine aufschlüsselung der einzelnen zeiten, um davon ausgehend den prozess zu beschleunigen:

proof of concept:

Timecheck: pures rendern:32Ms sidebar:126Ms highlight:120Ms proposedsymbolverarbeitung:0MS scroll:33Ms rahmensetzen:31Ms styleMDZeit:0Ms

simpletest.md

Timecheck: Parsen von 4114 Zeichen und 188 Elementen brauchte: 22ms - Rendern brauchte:111ms pures rendern:37Ms sidebar:46Ms highlight:5Ms proposedsymbolverarbeitung:0MS scroll:15 rahmensetzen:7 styleMDZeit:1

proof of concept.md, rahmensetzen ausgestellt:

Timecheck: Parsen von 17509 Zeichen und 298 Elementen brauchte: 12ms - Rendern brauchte:367ms pures rendern:45Ms sidebar:146Ms highlight:163Ms proposedsymbolverarbeitung:0MS scroll:12 rahmensetzen:0 styleMDZeit:1

[gaenseklein]

nochmal proof of concept mit allem: Timecheck: Parsen von 17560 Zeichen und 298 Elementen brauchte: 11ms - Rendern brauchte:314ms slidenotes.js:4289 Timecheck: pures rendern:38Ms sidebar:124Ms highlight:134Ms proposedsymbolverarbeitung:0MS scroll:17 rahmensetzen:1 styleMDZeit:0

simpletest.md: Timecheck: Parsen von 4114 Zeichen und 188 Elementen brauchte: 24ms - Rendern brauchte:74ms pures rendern:21Ms sidebar:44Ms highlight:6Ms proposedsymbolverarbeitung:0MS scroll:1 rahmensetzen:1 styleMDZeit:1

ergebnisse

highlight und sidebar sind absolute performance-fresser. rahmensetzen frisst dann zeit, wenn die größe vom texteditor nicht in pixeln festgelegt ist. da das aber auch zu ruckeln führt hab ich das eh wieder auf pixel festgelegt - da sprang die zeit runter vom 35Ms auf 1Ms bis 0Ms. ist also dann zu vernachlässigen. scheinbar macht die dynamische Größe und das Umrechnen in pixeln hier schwierigkeiten. auch scroll ist seit dem von 35Ms auf 17 gesunken, wobei für mich fraglich ist, warum ich an dieser stelle scroll ausführen muss? denke, da war mal was aber evtl. mal testweise ausstellen und gucken, in welchem sonderfall ich das wirklich brauche und nur darauf beschränken wenn möglich. das spart nochmal 17Ms.

highlight ist abhängig davon, wieviel es zu tun hat. bei nur einer seite mit einem überschaubaren codeblock scheint es nicht so dramatisch zu sein, siehe simpletest.md. bei proof of concept kam aber raus, dass sobald viel code da ist das auch zu einem absoluten performance-fresser wird. (146Ms) highlight könnte evtl. bei partiellem rendern beschleunigt werden, indem nur die veränderten seiten erneut mit highlight überzogen werden. das würde highlight wieder performant machen.

größter fresser ist die sidebar. die sidebar ist momentan mit vielen text-veränderungen aufgebaut und ich denke, dass ihre exorbitante zeit genau daher rührt. partielles rendern könnte aber auch hier die performance auf ein erträgliches maß reduzieren. (testseite mit titel, verschachtelter liste, chart und text kommt auf 7ms, während das rendern des hintergrundes bei 3ms liegt) das problem mit partiellem rendern ist halt nur, dass ich das nicht immer machen kann - d.h. es wird im worst-case zu deutlich höheren verzögerungen kommen.

[gaenseklein]

die sidebar hat folgenden zeitaufbau: generate sidebar from0 to 328 lines:328/328 gesamt:83 preparation:12 check lineheight:0 add new lines52 loop 1:4 loop2:15 wobei check lineheight nur auf 0 ist weil ich das schon vorher erledigt habe - vorher wurde das bei jedem durchlauf gemacht. dadurch spare ich schonmal ca. 35Ms. bleiben 83 Ms im Worstcase. Bestcase wenn Seite gefunden wurde: generate sidebar from314 to 328 lines:328/328 gesamt:35 preparation:0 check lineheight:1 add new lines31 loop 1:1 loop2:2 noch nicht eingearbeitet ist das durchscrollen etc, wodurch es momentan noch zu fehlern mit der carretline kommt und die sidebar dabei jedesmal komplett neu aufgebaut wird obwohl eigentlich ein bestcase da ist.

[gaenseklein]

bestcase wird jetzt besser abgefragt, es kommt aber noch zu fehlern, wenn bestimmte bedingungen erfüllt sind. und zwar wenn die letzte zeile einer seite ein element enthält, was über mehrere zeilen geht - bspw. eine abgeschlossene liste. dann wird diese liste weiterhin eingerückt angezeigt.

[gaenseklein]

Timechecks (rendern ist noch nicht optimiert, nur sidebar):

proof of concept.md

worst case

pures rendern:32-47Ms sidebar:89-137Ms

bestcase/pfeiltastenbewegung:

pures rendern: 0Ms (wird nicht neu gerendert) sidebar: 5-15Ms

bestcase/eine seite wird bearbeitet:

pures rendern: 28-39Ms sidebar: 30-36Ms

[gaenseklein]

dadurch, dass die sidebar im renderprozess aufgerufen wurde war sie stark verlangsamt. denn sie musste während der bearbeitung immer wieder auf den renderprozess warten, was zu deutlich zu langsamen zeiten führte. durch ein setTimeout habe ich den aufbau der sidebar nach hinten verschoben, was den aufbau der sidebar extrem beschleunigt im bestcase. vorheriger bestcase nach neuem parsen (bspw. klick mit maus irgendwohin) war bei 5-facher proof-of-concept trotz aller optimierungen bei 350-400ms (worstcase: 1700ms). 10-faches proof-of-concept: rendern braucht: 1209Ms, Sidebar braucht 8116Ms. (worstcase) klick mit maus: rendern braucht: 1219Ms, Sidebar braucht 25Ms

[gaenseklein]

Fehler tritt jetzt auch auf, wenn cursor vorher in einem multiline-element ist und dann mit der maus auf andere slide geklickt wird

[gaenseklein]

sidebar ist nicht mehr vorgesehen zur zeit