Bufferedstreams

eldok

Mitglied
Sry, wenn ich hier zu viele Fragen stelle^^ Finde das Forum genial, habe einiges durchgelesen.

Mir ist der Vorteil noch nicht so klar, wenn ich einen Buffer benutze.

Geht es eher darum, dass ich mit den Dateien arbeiten kann bevor alles geladen wurde? Wie z.B. bei Youtube, schauen bevor es geladen wurde.

Oder hat es eher mit dem schnelleren lasen zu tun. Das nicht Byte für Byte gelesen wird, sondern ein Block gesammelt wird und dann weiter verschickt wird. Hier ist es mir aber von der Technik nicht klar, wieso das "sammeln" schneller abläuft wie das lesen/bearbeiten Byte für Byte.
 

mrBrown

Super-Moderator
Mitarbeiter
Wie z.B. bei Youtube, schauen bevor es geladen wurde.
Du kannst YouTube-Videos schauen, bevor sie geladen sind? Die Funktion wünsche ich mir auch ;)


Oder hat es eher mit dem schnelleren lasen zu tun. Das nicht Byte für Byte gelesen wird, sondern ein Block gesammelt wird und dann weiter verschickt wird. Hier ist es mir aber von der Technik nicht klar, wieso das "sammeln" schneller abläuft wie das lesen/bearbeiten Byte für Byte.
Das ist es (und das ist das gleiche wie bei Youtube-Videos). Einen Block auf einmal zu laden, ist schneller als die einzelnen Teile des Blocks einzeln. Als Gedankenbeispiel: Du musst einen Großeinkauf machen, holst du dann einmal alles auf einmal oder jedes Teil einzeln? ;)
 

eldok

Mitglied
With a BufferedInputStream, the method delegates to an overloaded read() method that reads 8192 amount of bytes and buffers them until they are needed. It still returns only the single byte (but keeps the others in reserve). This way the BufferedInputStream makes less native calls to the OS to read from the file.
For example, your file is 32768 bytes long. To get all the bytes in memory with a FileInputStream, you will require 32768 native calls to the OS. With a BufferedInputStream, you will only require 4, regardless of the number of read() calls you will do (still 32768).

Jetzt bin ich nur verwirrter.
Es geht nicht um die Bytes, die einen Vorteil verschaffen sondern darum, dass nur ein Call erfolgt an das Betriebssystem und dann doch ein Byte nach dem anderen gelesen wird anstatt ein Call, ein Byte, weiterer Call, weiterer Byte usw.. ? Und falls bis hier hin stimmt, wie kommt er auf 4?
 

mihe7

Top Contributor
Und falls bis hier hin stimmt, wie kommt er auf 4?
32 KiB / 8 KiB = 4

Es geht nicht um die Bytes, die einen Vorteil verschaffen sondern darum, dass nur ein Call erfolgt an das Betriebssystem und dann doch ein Byte nach dem anderen gelesen wird anstatt ein Call, ein Byte, weiterer Call, weiterer Byte usw.. ?
Mal ein vereinfachendes aber hoffentlich anschauliches Beispiel. Du hast einen Datenträger mit einer Zugriffszeit von sagen wir mal 10 ms und einer Transferrate von 16 MiB/s. D. h. unabhängig davon, wie viele Daten gelesen werden, benötigt jeder Zugriff mindestens 10 ms.

Wenn Du für jedes Byte einzeln auf den Datenträger zugreifst, brauchst Du für 8 KiB mindestens 8.192 x 10 ms = 81920 ms, also knapp eineinhalb Minuten. Gehst Du dagegen her und lädst die 8 KiB auf einen Schlag, brauchst Du 10 ms + 8 KiB / (16 MiB/s) = 10 ms + 0,5 ms = 10,5 ms.

Der BufferedInputStream liest einen Block von 8 KiB auf einen Schlag in einen Puffer ein, der sich im RAM und damit in einem viel schnellerem Speicher befindet. Sagen wir mal, wir könnten aus dem RAM ein einzelnes Byte in 10 ns abrufen. Liest man nun jedes Byte einzeln aus diesem Puffer werden für alle Bytes eines Blocks 8192 x 10 ns = 81920 ns = 0,08192 ms benötigt. Ingesamt also unter 11 ms, was nun "etwas" weniger ist als 81920 ms.
 

Neue Themen


Oben