Warum Performancesteigerung durch EInsatz von BufferedWriter

[Guest]

Hallo,

ich lese gerade in einem Java Buch über Streams. Dort steht u.a. das die Klasse BufferedWriter (bzw. die entsprechenden Spezialisierungen) die Performance erhöht, da weniger Write Aufrufe/Zugriffe auf das Gerät erfolgen.
Analog ist es bei der BufferedReader Klasse.

Das verstehe ich nicht ganz. Wenn ich also 10 Schreizugriffe (z.B. Festplatte) durchführe, dann würde 10 mal write aufgerufen und bei BufferedWriter weniger? Wäre prima, wenn mir das jemand mal erläutern könnte.

 

[Der Müde Joe]

>Wäre prima, wenn mir das jemand mal erläutern könnte.

Du liest den ganzen Batzen in den Buffer (Speicher) und wenn du
das einzelne Zeichen dann brauchst, liesst du es vom Speicher.
Wenn der Speicher leer ist,füllst du den Buffer wieder.

vs.

Lies ein Zeichen, lies ein Zeichen, lies ein zeichen....

Speicher ist im Gegesatz zu HD-Zugriffen schnell

EDIT
oh und für write....

Schreib in Speicher, Schreib in Speicher, speicher voll
flush den speicher --> Schreiben auf HD
und das gleiche von vorne

 

[Gast]

Ah, ok. Danke Aber wenn der BufferedReader/Writer so toll ist wegen des Performancegewinns, warum braucht man dan überhaupt noch das "einzelne" Einlesen/Schreiben der normalen Reader/Writer? Zwar benötigt der Konstruktor des BufferedReaders/Writers einen normalen Reader/Writer aber man hätte doch darauf verzichten können und nur das Konzept BufferedReader/Writer einführen können. Denn was für Vorteile sollte dann das einzelne Lesen/Schreiben bringen?

 

[SlaterB]

ein Buffer verzögert Ein- und Ausgaben,
du schreibst eine Zeile von 100 Bytes, aber der Writer wartet mal eben bis es 16.000 sind, solange passiert gar nix,
das Programm könnte hängen, falls der User kein flush() oder noch mehr Schreibvorgänge auslöst,

ein Stream sollte grundsätzlich nur das sein, was sein Name auch aussagt,
nicht alle möglichen Sonderfunktionen mitsamt erforderlichen Bedienungsvorschriften enthalten

unnötiger Overhead wie ein 20 kb Arbeitsspeicher belegender Buffer ist sowieso generell nicht gerne als Standard gesehen

 

[Der Müde Joe]

Die Streams bzw Reader/Writer machen übrigens gebrauch vom Decorator Pattern. Drum benötigt der BufferedXXX auch einen Stream/R/W im Konstruktor. Er benutzt den unterliegenden was auch immer und fügt einen Buffer hinzu.

 

[Gast]

Hallo,

danke für die Antworten

>ein Stream sollte grundsätzlich nur das sein, was sein Name auch >aussagt,
>nicht alle möglichen Sonderfunktionen mitsamt erforderlichen >Bedienungsvorschriften enthalten

Ich verstehe es trotzdem noch nicht. Wenn ein direktes Aufrufen von write zuviel overhead erzeugt, wieso es dann trotzdem sinnvoll ist nicht immer den Puffer zu nehmen.

Wann ist es also sinnvoll den Puffer zu nutzen und den damit verbundenen Performancegewinn und wann (warum) nicht.

Vielen Dank

 

[Beni]

Ein Stream muss nicht unbedingt in eine Datei führen.

Beispiel: ein Stream führt auf die Konsole. Jetzt gibt man ihm zu schreiben "Geben Sie eine Nummer zwischen 0 und 100 ein und drücken Sie Enter". Diese Nachricht sollte keinesfalls in irgendeinem Buffer stecken bleiben, weil der Benutzer sonst niemals etwas eingibt.

Anderes Beispiel: ein Stream führt in einen internen Cache (eine "simuliertes Datei"). Da ist es egal wie oft write aufgerufen wird, nur die gesammte übertragene Menge von Bytes zählt. Ein Buffer wäre nur ein unnötiger Overhead.

 

[Ebenius]

Hallo Gast,

Es gibt einen FileReader der nichts anderes kann als Zeichen aus einer Datei zu lesen. Es gibt einen StringReader der nichts anderes kann als Zeichen aus einem String zu lesen. Es gibt einen CharArrayReader der nichts anderes kann als Zeichen aus einem char-Array zu lesen. Ich kann mir weitere Reader bauen die ebenfalls Zeichen von irgendeiner Quelle lesen, und jede dieser Implementationen kümmert sich nur um das wofür sie da ist: Zeichen von einer Quelle zu holen. Wenn jemand Daten aus der Quelle XYZ holen möchte, dann nutzt er einfach einen BufferedReader der wiederum einen XYZReader benutzt. Damit muss man sich nicht bei jeder einzelnen Reader-Implementation darum kümmern, dass dieser wiederum puffern kann.

Wann ist es also sinnvoll den Puffer zu nutzen und den damit verbundenen Performancegewinn und wann (warum) nicht.

Es ist beinahe immer sinnvoll einen Puffer zu benutzen um die Geschwindigkeit zu erhöhen. Es ist nur nicht sinnvoll den Puffer überall neu zu erfinden; daher sieht es in der Realität meist so aus:

new BufferedReader(new FileReader(myFile));
new BufferedReader(new StringReader(myString));
new BufferedReader(new CharArrayReader(myCharArray));
new BufferedReader(new XYZReader(...));

Für Writer, InputStreams und OutputStreams entsprechend.

Ebenius

 

[SlaterB]

besonders dämlich ist es beispielweise, wenn man
write(byte[] mit schon 10000 bytes);
aufrufen will,
also große Mengen Daten schreibt,
oder wenn man eh nur genau eine Nachricht schreibt

ein Puffer macht in den Anwendungsfällen
'viele kurze Schreibvorgänge, am Ende ist aber nur ein fertiges Ergebnis wichtig' +
'viele kurze Lesevorgänge auf Daten die komplett zur Verfügung stehen' Sinn,
aber auch dann kann man noch weiter nachdenken,

z.B. Aufteilung:
ein Log-Stream verzweigt sind, schreibt zum einen auf die Konsole, zum anderen in eine Datei,
die drei einzelnen Streams (Log, Konsole, File) müssen nicht jeder puffern, es reicht wenn das nur Log macht

oder Reihenschaltung:
Log, Inhalts-Filter, Sichrheits-Filter, Writer der Encoding bestimmt, Zipper, File

sechs Streams in Reihe geschaltet mit einzelnen Aufgaben, nicht jeder von diesen brauch einen Puffer, neben dem obersten, Log,
hat aber vielleicht der Zip-Stream auch einen, um möglichst optimal Daten zu komprimieren

 

[Gast]

Hallo,

danke für die, erfreulicherweise, zahlreichen Antworten. OK, wann ein Puffer Sinn macht habe ich glaube ich verstanden: Wenn man den erwähnten Geschwindigkeitsvorteil erreichen will.


>Es gibt einen FileReader der nichts anderes kann als Zeichen aus >einer Datei zu lesen.
Wenn ich nun also einen FileReader/Writer betrachte, dann macht es dort ja Sinn zu puffern, oder? D.h. im Fall des FileReaders/Writers braucht man eigentlich immer einen Puffer. Oder warum sollte man Zeichen von/in eine(r) Datei einzeln auslesen?

Also ich denke ich hab zwar verstanden das ein Puffern bei bestimmten Anwendungen nicht sinvoll ist (Konsole usw.) aber warum man den FileReader/Writer nicht standardmässig puffert, d.h. warum es nicht nur einen BufferedFileReader/Writer gibt leider noch immer nicht

 

[Ebenius]

Also ich denke ich hab zwar verstanden das ein Puffern bei bestimmten Anwendungen nicht sinvoll ist (Konsole usw.) aber warum man den FileReader/Writer nicht standardmässig puffert, d.h. warum es nicht nur einen BufferedFileReader/Writer gibt leider noch immer nicht

Man benutzt normaler Weise FileReader/Writer/Streams immer in Zusammenhang mit BufferedReader/Writer/Streams. Aber man baut den Puffermechanismus nicht in jede Klasse neu ein. Warum auch? Der Weg funktioniert doch super so, ist gut gekapselt, wenig redundant...

Ebenius

 

[Schandro]

Warum sollte es standardmäßig sein? Warum sollte man den Java-Developer unnötig einschränken? Selbst wenn nur 0,1% der Benutzer den FileReader ohne Puffer benutzen wollen, sind es die 2 Sekunden Tipparbeit pro BufferedReader(..) wert, das man diese 0,1% vor den Kopf stößt? Nein, weil man imho den Benutzer von etwas immer die größtmöglichste Freiheit lassen sollte...

 

[Wildcard]

Es folgt dem Unix Gedanken. Ein Tool mit genau einem Zweck und Tools lassen sich beliebig kombinieren.

 

[Gast]

Hallo,

>den FileReader ohne Puffer benutzen wollen

danke. OK. Aber in welchem Szenario wäre es denn sinnvoll nur einen FileReader ohne BufferedReader zu nutzen?

 

[SlaterB]

ein FileReader würde auf keine Fall puffern, denn der ist selber schon ein zusammengesetzter Stream,
weiter unten steht ein FileInputStream, welche Daten byte-orierntiert einliest,
ein Reader darauf interpretiert diese Daten als Zeichenketten

ein Puffer macht beispielsweise dann keinen Sinn, wenn man weiter oben selbstständig noch einen Puffer drauspackt,
beispielsweise in einem Programm
new BufferedReader(getAnyReader()); wobei getAnyReader() nach irgendwelchen Programmeinstellungen mal einen FileReader
oder sonst einen anderen Reader liefert,
niemand will an dieser Stelle unterscheiden, ob schon ein Puffer in der Kette drin ist oder nicht

außerdem könnte man, wie schon geschrieben, sich dazu entschließen, gleich 10.000 Bytes/ Zeichen auf einmal zu lesen,
weil man die für eine komplexe Programmverarbeitung auf einmal brauch oder für höhere Standardzwecke wie Komprimieren/ Dekomprimierung

in diesen einfachen Beispielen wäre das Problem der Puffer wohl nicht mehr als ein unnötiger zusätzlicher Speicher,
aber auch das kann schon kritisch sein,
etwas wenn viele Dateien gleichzeitig geöffnet sind und aus jeder nur wenige Daten auf einmal ausgelesen werden sollen,
und der hohe Speicherbedarf des Pufferns hinter der höheren Bearbeitungsdauer zurücksteht


Caching ist nie ein Selbstzweck,
wer nur eine Telefonnummer braucht, reißt auch nur eine Seite aus einem öffentlichen Telefonbuch,
statt das ganze Buch mitzuschleppen

-------

dass es nicht ausgeschlossen wäre, der Grundansicht 'Ein Tool mit genau einem Zweck und Tools lassen sich beliebig kombinieren.' zu widersprechen,
zeigt, wie schon angedeutet, die Klasse FileReader selber,
deren kompletter Quellcode lautet in etwa:

public class FileReader extends InputStreamReader {

    public FileReader(File file) throws FileNotFoundException {
	super(new FileInputStream(file));
    }

    // + paar ähnliche Konstruktoren
}

new FileReader(file);
dient also ganz allein als Ersatz für das längere Konstrukt
new InputStreamReader(new FileInputStream(file));

genauso könnte man sich eine Klasse 'BufferedFileReader extends BufferedReader' schreiben,
die intern einen FileReader verwendet,

es ist denkbar, ja

und wer das nicht möchte, könnte dann direkt FileReader oder gar FileInputStream verwenden

 

[Ebenius]

Caching ist nie ein Selbstzweck,
wer nur eine Telefonnummer braucht, reißt auch nur eine Seite aus einem öffentlichen Telefonbuch,
statt das ganze Buch mitzuschleppen

[off topic] Gewissen Innenministern traue ich zu, ganze Sammlungen verschiedener Ausgaben mit sich rum zu schleppen.

 

[Gast]

Hallo,

danke für die Antwort...

>außerdem könnte man, wie schon geschrieben, sich dazu >entschließen, gleich 10.000 Bytes/ Zeichen auf einmal zu lesen,
Ja ist das nicht genau das was auch ein Puffer macht, statt eines einzelnen Zeichens gleich eine ganze Menge zu lesen?

 

[SlaterB]

der Puffer soll das im Hintergrund machen, wenn man selber nur 100x 100 Bytes liest (ein Lesevorgang statt 100)

wenn man aber in einem Lesevorgang 10.000 Bytes liest, dann kann das jeder Stream auch super in einem Lesevorgang machen, der muss dann nicht mehrmals auf die Festplatte zugreifen,

beim Lesen von 10.000 Bytes würde der FileReader diese superschnell lesen,
der BufferedReader diese auch superschnell vom FileReader bekommen,
dann wahrscheinlich superschnell in seinen Puffer schreiben und direkt wieder herauslesen
oder auch im Ideal-Fall direkt weiterreichen,

aber selbst in diesem Ideal-Fall wäre der Puffer in diesem Fall eine Bremse, ein unnötiger zusätzlicher Verarbeitungsschritt,
denn durch die Größe der Anfrage kann der FileReader bereits selbstständig optimal 10.000 Bytes in einem Schritt lesen

ein Puffer kann nur verhindern, dass ein Stream mehrere Zugriffe macht, in dem er dem Stream sagt, bitte ganz viel aufeinmal einzulesen,
wenn der User das selber direkt dem Stream sagt, dann wird der Puffer überflüssig


edit:
new BufferedReader(new BufferedReader(new BufferedReader(..)));
wird auch nicht in jedem Schritt besser..

 

[Gast]

Hallo,

>der Puffer soll das im Hintergrund machen, wenn man selber nur >100x 100 Bytes liest (ein Lesevorgang statt 100)

Angenommen ich will 100 Bytes lesen, mit FileReader.read würde quasi das lesen 100 mal ausgelöst richtig? Ich kann mit FileReader jedoch auch gleich die 100 Bytes in einem Rutsch holen, richtig? Da brauche ich doch auch nur einen read Vorgang. Wozu dann also den Puffer? Ich dachte der Puffer macht genau das, 100 Bytes (als Beispiel) in einem Rutsch lesen.

 

[Gast]

Nachtrag:

>wenn der User das selber direkt dem Stream sagt, dann wird der >Puffer überflüssig

Ja dann brauch ich doch den Puffer nicht und und sag es gleich. Kann mir bitte dann mal jemand sagen wo der Unterscheid ist ob ich nun mit dem Puffer 100 Bytes gleich lese oder mit dem FileReader?

 

[SlaterB]

ganz schön beratungsresistent..

Programm:
reader.read(100 bytes);
reader.read(100 bytes);
reader.read(100 bytes);
reader.read(1000 bytes);
reader.read(10000 bytes);


ist reader ein FileReader, so wird dies zu genau 5 Zugriffen auf die Festplatte führen,
egal wieviele Bytes angefordert werden, jedes read = ein Lesevorgang
(mehr oder weniger, was da intern alles passiert, sei mal außen vor gelassen)

ist reader ein BufferedReader, so werden es je nach Puffer-Größe weniger Lesevorgänge,
angenommen der Puffer ist 10.000 bytes groß,
so werden beim ersten read nicht nur 100 bytes sondern gleich 10.000 bytes gelesen,
für den zweiten bis vierten read kann auf den Puffer zurückgegriffen werden,
erst beim 5. großen read reicht der Inhalt des Puffers nicht, dann muss ein zweiter Festplattenzugriff erfolgen

anderes Programm:
reader.read(10000 bytes);
reader.read(10000 bytes);
reader.read(10000 bytes);
reader.read(10000 bytes);


bei einer angenommenen Puffer-Größe von 10.000 oder weniger bytes
würde hier jedes read zu einem Festplattenzugriff führen, egal ob ein Puffer da ist oder nicht, denn der Puffer kann hier nicht helfen,
kann nicht so viele Daten aufnehmen, dass es für zwei read reicht

 

[Ebenius]

Möchte nur mal darauf hinweisen, dass hier im Eifer des Gefechts Bytes mit der Reader-Klasse gelesen werden. Das sollen natürlich InputStreams sein; nur dass es nicht so falsch stehen bleibt.

 

[Gast]

@slater,@ebenius...

Danke. Ich glaube jetzt habe ich es verstanden! Danke. Ich kann somit die Anzahl der Schreib/Lesezugriffe verringern, d.h. die Performance erhöhen. Wenn ich aber nur einen Lese/Schreibzugriff hätte, wäre es unnötige Speicherverschwendung einen großen Puffer anzulegen, da er sowieso nicht weiter gebraucht wird.

Ich hoffe das ist so i.O.?

Also DANKE, DANKE, DANKE Hätte nicht gedacht das es noch so hilfsbereite Leute gibt

 

[Ebenius]

Ich kann somit die Anzahl der Schreib/Lesezugriffe verringern, d.h. die Performance erhöhen. Wenn ich aber nur einen Lese/Schreibzugriff hätte, wäre es unnötige Speicherverschwendung einen großen Puffer anzulegen, da er sowieso nicht weiter gebraucht wird.

Das klingt ganz gut so, ja.

Natürlich nicht nur die Anzahl, sondern auch die Verzögerung, bei aufeinanderfolgenden Leseoperationen wenn I/O über langsame Verbindungen stattfindet, dann sind die Daten eben oft schon im Puffer, bevor Du sie haben wolltest → Du wartest nicht so lang.

Ebenius