[C#] RichTextBox vullen is langzaam

[WVL_KsZeN]

Ik zit met een probleempje waar ik niet helemaal uitkom, ook google-fu wil me niet zo helpen.

Ik ben bezig met een applicatie die een zut data in ascii formaat moet verwerken. Voor debugging (en omdat de files soms niet helemaal netjes zijn) heb ik een tabje een RichTextBox waarin ik optioneel de data aan de gebruiker toon. Het gaat soms om best redelijk grote files (500kB tot 8MB).

Het blijkt echter iedere keer dat het vullen van de RichTextBox nogal wat tijd kost, ik vul de RichTextBox in 1 keer :

code:

rtbDebugTextBox.Text = dataString;

Simpeler kan het niet, toch duurt alles nogal lang (een seconde voor 500kB aan text). Volgens mij ligt dat aan het 'omzetten' van een string naar rtf. Echter boeit het hele rtf me niets en wil ik niets omzetten. Er hoef niets gehighlight te worden oid. Het enige dat ik wil is de input data kunnen zien en erin kunnen zoeken. Een gewone TextBox gebruiken gaat niet, die is beperkt tot 64kB aan data.

Ik kan echter niet vinden hoe ik de omzetting van string->rtf sneller zou kunnen krijgen. Iemand een suggestie?

[diondokter]

Ik heb geen idee of het sneller zou zijn, maar misschien kun je de Append method gebruiken...

Ik kan me voorstellen dat dit geoptimaliseerd is. Daarbij kun je de string eerst opdelen en daarna toevoegen.

Nogmaals ik noem maar mogelijkheden... Ik weet niet of dit sneller is...

[ Voor 16% gewijzigd door diondokter op 25-04-2014 12:06 ]

[WVL_KsZeN]

Oh, dat ben ik vergeten neer te schrijven : als ik de data opsplits in een aantal kleinere delen en probeer te appenden, dan duurt het nog langer. Blijkbaar wordt iedere keer dat je iets append de complete data opnieuw geformat, wat dus in totaal 2x zo lang duurt.

[alex3305]

RichTextBox is van zichzelf een heel langzaam ding omdat het gebruik maakt van RTF op de achtergrond. Met andere woorden, je gooit er een hoop tekst in, dat wordt dan omgezet naar RTF, dan wordt de inhoudt teruggezet en getekend.

Als je alleen platte data wilt zou ik gebruik maken van een gewone Textbox. Die is wel snel en kan ook gewoon met multi-line en dergelijke omgaan. Of als je fancy dingen wilt zoals regelnummers en dergelijke zou ik gebruik maken van FastColoredTextBox die heb ik laatst ook gebruikt in een project met syntax highlighting en werkte erg snel en gebruiksvriendelijk. Beter dan mijn eerder oplossing met het selecteren, parsen en tekenen in ieder geval.

[WVL_KsZeN]

alex3305 schreef op vrijdag 25 april 2014 @ 12:18:
RichTextBox is van zichzelf een heel langzaam ding omdat het gebruik maakt van RTF op de achtergrond. Met andere woorden, je gooit er een hoop tekst in, dat wordt dan omgezet naar RTF, dan wordt de inhoudt teruggezet en getekend.

Als je alleen platte data wilt zou ik gebruik maken van een gewone Textbox. Die is wel snel en kan ook gewoon met multi-line en dergelijke omgaan. Of als je fancy dingen wilt zoals regelnummers en dergelijke zou ik gebruik maken van FastColoredTextBox die heb ik laatst ook gebruikt in een project met syntax highlighting en werkte erg snel en gebruiksvriendelijk. Beter dan mijn eerder oplossing met het selecteren, parsen en tekenen in ieder geval.

Ik ga eens naar FastColoredTextBox kijken!

[WVL_KsZeN]

Helaas geen stap verder gekomen. FastColoredTextBox lijkt wel snel te zijn voor highlighten (ten opzichte van RichTextBox), maar voor het inlezen van veel data nog langzamer..

Ook ontdekt dat je toch meer data in een gewone TextBox kunt proppen (MaxLength op 0 zetten), maar helaas blijkt een gewone textbox óók langzamer dan RichTextBox. Dat had ik niet verwacht!

Doe ik nu iets fout of kan het gewoon niet sneller?

[diondokter]

Moet het dan persé in een textbox loggen, of mag het ook in een tekstbestand?

Of (als dat kan in jouw geval) zorg voor meerdere textboxes die ook op verschillende threads lopen. Ik kan me namelijk niet voorstellen dat je 1.5mb aan tekst sowieso in een keer kan zien. Met die meerdere threads gaat die conversie een stuk sneller.

[RobIII]

Ik zou 't gewoon faken. Eigen scrollbar maken die je gebruikt om een offset te bepalen en dan alleen zoveel als er in de textbox past daadwerkelijk tonen. Zoals een Listview een VirtualMode heeft dus. Je maakt een soort viewport van je textbox (of hell, mogelijk zelfs je RichTextBox). Extra voordeel is dat je daarmee niet in 1 klap 8MB data hoeft in te lezen; je springt naar een bepaalde berekende offset in je file (a.d.h.v. de scrollbarpositie), leest een paar KB (net voldoende om te tekstbox te vullen) et voila. Wat wel weer roet in 't eten kan gooien zijn in text-wrap, linefeeds e.d. Dat is ook precies de reden waarom een notepad (en alternatieven) langer zullen doen over 't openen van een groot tekstbestand dan een hex-editor; die hoeft zich niet te bekommeren om die zaken; je hebt vaste "regel-lengtes" van X tekens (lees: X bytes/octets/whatever) en kunt zo dus zonder fratsen meteen je offset gebruiken en data beginnen te tonen. Het is dus ook een beetje afhankelijk van je data/daadwerkelijke tekst hoe goed/snel je dit zelf zult kunnen implementeren.

Then again vraag ik me af hoeveel nut het heeft een gebruiker met 8MB aan meuk te confronteren; ik zou in eerste instantie eens gaan kijken of dat überhaupt niet anders kan.

[edit]
Ik heb even een rudimentaire opzet gemaakt; er schort nog vanalles aan (scrollwheel doet niets, voor elke scheet wordt disk I/O gedaan (dat kan stukken slimmer), scrollen door de cursor "buiten de viewport" te bewegen werkt niet etc. etc. etc.) maar demonstreert 't idee en dat was 't... euh... idee

[ Voor 60% gewijzigd door RobIII op 26-04-2014 00:43 ]

[WVL_KsZeN]

Hmm.. misschien kan ik beter uitleggen waar het voor is :-)

Het gaat om gegevens (hexidecimaal in ASCII formaat. dus bv 01AA43BC) die vanuit automaten op straat worden gestreamd naar onze server. Voor de dataverbinding gebruiken we HSDPA en UMTS modems. Helaas staan een aantal automaten op plaatsen waar de ontvangst nogal slecht is. de vebinding is niet altijd up, waardoor er soms gaten in de stream ontstaan. Helaas heeft de data in de stream geen enkele vorm van foutcorrectie. (het is een gestandaardiseerd gegevensformaat, ik zou het anders hebben gedaan...) Fouten in de data kan ik er alleen uitpikken door een consistentie controle.

De data is als volgt opgebouwd : een byte met een berichttype (bijvoorbeeld 05), daarna het aantal gegevens in het bericht (bv 18 = 24 data units) en daarna de data. Een bericht bestaat uit maximaal iets van 60 tekens en past altijd op 1 regel. Ik kan dus bijvoorbeeld een check doen op de consistentie : klopt de lengte van deze regel met het berichttype en het opgegeven aantal data units?

Een ander type check is als volgt : bericht 05 geeft wijzigingen aan, bijvoorbeeld de meting van waarde blaat is verandert in een 1. Als mijn voorgaande waarde echter ook al een 1 was, dan mist er blijkbaar een bericht in de datastream.

Voor al deze consistentie-fouten wil ik een melding geven en de (expert-) gebruiker de mogelijkheid geven om de gegevens met de hand in te zien, zonder direkt een andere editor te hoeven openen. (ook kan mijn programma direkt naar de regel springen waar een consistentiefout is geconstateerd). Je kunt daanra handmatig een aanpassing in het bestand maken of er commentaar bij zetten (en het bestand weer opslaan) en daarna verder gaan.

De grootste hoeveelheid gegevens die ik verwacht in 1x te verwerken is +-8MB.

Nu is het stomme dat het ophalen van de data uit de server, het filteren van de data en controleren op consistentie in no-time is gebeurt, maar het vullen van de textboxes als er fouten zijn geconstateerd duurt echt een eeuwigheid.. (terwijl dat nu juist de simpelste actie is!)

@Rob : ik ga eens naar je voorbeeld kijken, helaas kan ik hem hier niet openen (heb hier vs 2010), blijkbaar heb jij een nieuwere (2012 of 2013?).

[ Voor 10% gewijzigd door WVL_KsZeN op 26-04-2014 16:53 ]

[WVL_KsZeN]

Even pielen en het voorbeeld is omgezet naar VS 2010 :-) Dat viel best mee. Ik ben nu een beetje aan het hacken, horizontale scrollbar toegevoegd en resize toegevoegd. Nu nog eens kijken waarom enters nog niet werken..

OK, ik begrijp de moeilijkheid van regels die niet allemaal dezelfde lengte hebben, en waarom dat mis gaat bij het scrollen..

Ik denk dat ik het als volgt ga oplossen :
1) ik wil geen wordwrap, dus bij mij blijft alle data van 1 regel op 1 regel. Als de view te klein is maak ik we l een scrollbar aan.
2) ik tel het aantal regels in het bestand en maak een tabel met de offset van elke regel. Die tabel icm met het aantal regels gebruik ik om de positie van de scrollbar te vertalen naar een offset.
3) ipv lezen uit een file lees ik de file 1x in een string in, om geen disk-io te hebben.

Daar maar eens mee beginnen! :-) en daarna uitzoeken hoe ik kan scrollen met de cursor.

[ Voor 61% gewijzigd door WVL_KsZeN op 26-04-2014 17:26 ]

[Gomez12]

WVL_KsZeN schreef op zaterdag 26 april 2014 @ 16:20:
...
Voor al deze consistentie-fouten wil ik een melding geven en de (expert-) gebruiker de mogelijkheid geven om de gegevens met de hand in te zien, zonder direkt een andere editor te hoeven openen. (ook kan mijn programma direkt naar de regel springen waar een consistentiefout is geconstateerd). Je kunt daanra handmatig een aanpassing in het bestand maken of er commentaar bij zetten (en het bestand weer opslaan) en daarna verder gaan.

De grootste hoeveelheid gegevens die ik verwacht in 1x te verwerken is +-8MB.

Wat ik nog even niet snap is waarom je 8MB wilt gaan tonen als het maar om een paar regels gaat die de check niet halen...

Niemand gaat die 8MB lezen / bewerken, iedereen is enkel maar geinterresseerd in een paar regels.

Toon dan ook enkel die regels zou ik zeggen en je hebt geen probleem meer.

[Damic]

Regel per regel in een listbox gooien en als je een regel wil analiseren (door op de klikken) doen je de gegevens apart in een text box!

btw kun je een stukje van je code hier dumpen of ergens anders?

[ Voor 19% gewijzigd door Damic op 26-04-2014 18:00 ]