[java] snel grote textbestanden in lezen

[Alarmnummer]

Wie weet een manier om snel een grote text files in te lezen? De code die ik nu nog gebruik is in mijn ogen te langzaam.

code:

BufferedReader in = new BufferedReader(new FileReader(file));
String s = in.readLine();
StringBuffer stringBuffer = new StringBuffer();
while(s!=null)
{
   stringBuffer.append(s);
   stringBuffer.append("\n");
   s = in.readLine();
}

[Alarmnummer]

Op woensdag 31 oktober 2001 16:02 schreef Alarmnummer het volgende:
Wie weet een manier om snel grote text files in te lezen? De code die ik nu nog gebruik is in mijn ogen te langzaam.

code:

BufferedReader in = new BufferedReader(new FileReader(file));
String s = in.readLine();
StringBuffer stringBuffer = new StringBuffer();
while(s!=null)
{
   stringBuffer.append(s);
   stringBuffer.append("\n");
   s = in.readLine();
}

Heb al een verbetering gevonden.. de stringBuffer meteen de juiste grote geven.
stringBuffer = new StringBuffer((int)file.length());

[mbravenboer]

1. append('\n');

2. Waarom uberhaupt readLine gebruiken als je toch een \n invoert? Je kan dan in principe ook gewoon de hele file inlezen... Zou weleens een flink stukje sneller kunnen gaan.

3. nio zou het echte toverwoord moeten zijn .
Zie: java.nio.channels.FileChannel. Ik heb echter wel mijn twijfels of dat in dit geval nu echt veel resultaat zal opleveren. Ik denk dat het verplaatsen in de StringBuffer de meeste tijd eet. Maar ja, die memory-mapped IO zou ook weleens erg goed kunnen werken

Het standaard instellen van de StringBuffer grootte is trouwens inderdaad uitstekend .

[Alarmnummer]

Maakt niet zoveel uit als je nou stringBuffer.append("\n") of stringBuffer.append('\n') doet. Heb laatst even in de stringbuffer gekeken en hij maakt er zelf eerst toch een string van

Dus een nieuw string object wordt toch gemaakt, kan ik het net zo goed meteen zelf doen

En de reden dat ik readline gebruik is dat je niet alleen een \n tegen komt, maar ook \r\n van windows of \r van mac. (bestanden worden niet alleen door mijn editor veranderd)

En ik zal even bij die nio kijken.. thanx in ieder geval.

[mbravenboer]

Bij de docs van beta 3 zitten trouwens in docs/guide/nio/example enkele voorbeelden die iets met file io doen. Grep met reguliere expressies o.a.

[mbravenboer]

readline: snap, zoiets vermoedde ik al...

append(char): heel veel wordt naar een String omgezet, maar een char niet:

code:

public synchronized StringBuffer append(char c) {
    int newcount = count + 1;
    if (newcount > value.length)
      expandCapacity(newcount);
    value[count++] = c;
    return this;
}

Veel zal het niet uitmaken, maar toch

[mbravenboer]

Als je trouwens eens opmeet wat in totaal voor een flinke file het langs duurt: inlezen (s = ) of appenden, dan weet je gelijk of nio een oplossing kan zijn .

Nu ik de voorbeelden zo zie van memory-mapped IO denk ik dat het toch weleens behoorlijk wat zou kunnen schelen.... Grep en Sum zijn hele duidelijke voorbeelden in ieder geval .

[Alarmnummer]

Ben er intussen al achter dat het lezen we aardig snel gaat. Maar JEditorPane.setText(text) de boosdoener is :(:(
oja.. en stom dat ik er niet eerder naar kekeken heb
(kan niet overstappen op een JTextArea ivm toekomstige her aanschakeling syntax highlighting).

[mbravenboer]

Alarmnummer: Ben er intussen al achter dat het lezen we aardig snel gaat. Maar JEditorPane.setText(text) de boosdoener is :(:(

Hum... daar hebben Mr Bad Guy weer .

kan niet overstappen op een JTextArea ivm toekomstige her aanschakeling syntax highlighting.

Magic word: neem het component van jEdit (en dus ook van jext). Die is laaaaaaaaaaaaaiend snel.

[Alarmnummer]

Op woensdag 31 oktober 2001 16:34 schreef mbravenboer het volgende:

[..]

Hum... daar hebben Mr Bad Guy weer .
[..]

Magic word: neem het component van jEdit (en dus ook van jext). Die is laaaaaaaaaaaaaiend snel.

Maar gebruik een DefaultStyledDocument die verder geen stylen bevat. Ok voor ieder regel word weer een element aangemaakt. Maar dat het zo traag is... tjonge jonge.. (met syntax highlighten aan was ie al traag).. maar nu nog steeds..

[mbravenboer]

Alarmnummer: Maar gebruik een DefaultStyledDocument die verder geen stylen bevat. Ok voor ieder regel word weer een element aangemaakt. Maar dat het zo traag is... tjonge jonge.. (met syntax highlighten aan was ie al traag).. maar nu nog steeds..

Ik heb me ooit voorgenomen om er nooit meer naar te kijken... Als ik jou was zou ik me echt ff in dat jEdit component verdiepen. Kan je veel plezier aan beleven . Je krijgt bovendien een smak talen er gratis bij .

[Alarmnummer]

Op woensdag 31 oktober 2001 16:48 schreef mbravenboer het volgende:

[..]

Ik heb me ooit voorgenomen om er nooit meer naar te kijken... Als ik jou was zou ik me echt ff in dat jEdit component verdiepen. Kan je veel plezier aan beleven . Je krijgt bovendien een smak talen er gratis bij .

Zit er al in te rommelen

[Alarmnummer]

Het is wel een puinzooi zeg..

[mbravenboer]

Hij is in ieder geval erg groot ja .

[Alarmnummer]

Op woensdag 31 oktober 2001 17:15 schreef mbravenboer het volgende:
Hij is in ieder geval erg groot ja .

Als ze nou een paar losse elementen hadden gemaakt dan was het wel bruikbaar, maar alles is met elkaar geintegreerd. Kan hier niet veel mee.

[mbravenboer]

Zoveel afhankelijkheden zitten er toch niet in . Ik heb hem nog niet gebruikt, maar was het wel van plan (voor een TCP tunnel met XML messages) maar zag het op zich wel zitten...

In de Jext versie hoe je alleen maar even het JextFrame eruit te slopen dacht ik...