#What is buffered reader?

1 messages · Page 1 of 1 (latest)

primal plinth
#

From my understanding it takes a chunk of data and reads it byte by byte instead of taking all of the data at once leading to faster running time but I don't understand it in code why does it need the new(FileReader("file.txt"))) or smth like that for it to run

signal waveBOT
#

<@&987246399047479336> please have a look, thanks.

#

Here is an AI assisted attempt to answer your question 🤖. Maybe it helps! In any case, a human is on the way 👍. To continue talking to the AI, you can use </chatgpt:1108714622413963314>.

#
TJ-Bot
From my understanding it takes a chunk of data and reads it byte by byte instead of taking all of the data at once leading to faster running time but I don't understand it in code why does it need the new(FileReader("file.txt"))) or smth like that for it t

depth. Can someone explain it further?

A BufferedReader in Java is a class that reads text from a character-input stream, buffering characters so as to provide for the efficient reading of characters, arrays, and lines. It provides more efficient reading of data by reducing the number of I/O operations needed to read data from the input source.

When you use a BufferedReader, it reads data from an input source (such as a file or network connection) in chunks, rather than one byte at a time. This can improve the performance of your program because it reduces the number of system calls needed to read data.

The BufferedReader class also provides methods for reading characters, lines, and arrays of characters. It can be used with other input streams and readers in Java to add buffering capabilities.

In summary, a BufferedReader in Java is used to improve the efficiency of reading text data by buffering characters read from an input source. This can lead to faster running times for programs that need to read large amounts of text data.

- AI generated response
primal plinth
#

tldr is it just faster cause it reads in bigger chunks?

quartz copper
# primal plinth From my understanding it takes a chunk of data and reads it byte by byte instead...

reads it byte by byte instead of taking all of the data at once
That's wrong. Reading something from memory is a (potentially very) costly operation. If you can, you want to read as much as possible at once, i.e. you want to minimize how often you actually need to read from memory. If you read byte by byte then there will be stuff like caches (which is a CPU specific thing) that automatically, on the lowest level, perform some sort of buffering. But despite that, accessing these caches every time for each byte over and over again is still incredibly costly compared to just reading it all in one big swoop.

What a BufferedReader will do is use an internal buffer (as the name suggests). When you first call a read method on an instance of this, what will happen is that it'll immediately fill its whole buffer (let's say that's about 4 kB [explanation for why exactly this size would go too far here] or 4096 characters), i.e. it will read ahead, even if you asked it for way less. On the subsequent read calls what it will do is not do any read call (remember: accessing memory, or even worse, the hard drive, is slow), but it will simply give you text it read ahead earlier.
For short files this means a BufferedReader will only ever do one actual read call where it actually reads from memory or hard drive (technically you can't read from a hard drive, but again: let's not get in too deep).

#

why does it need the new(FileReader("file.txt")) or smth like that for it to run
Because a BufferedReader is "just" a "generic" (sorry, I have to put these quotation marks, because these statements are not technically correct) wrapper for any other kind of reader. You can kinda imagine it like the commander of another reader, that gives the reader further instructions on how to read, but only the reader knows what he's actually supposed to be reading, in this case it's a FileReader, so the reader reads a file, and the name is file.txt so it will read the file called file.txt

primal plinth
quartz copper
#

In Java you would probably use a String and set it's size to 1 << 13, but I'm kinda too lazy to look for the function rn

primal plinth
quartz copper
#

ah, bitshift.

#

it's a 1 (bit), shifted 13 spots to the left

primal plinth
#

ohh

#

so what would that do

quartz copper
#

Well, (1 << 13) = 2^13 = 8,192 (at this number I realized I should've written 1 << 12..., anyway): 8,192 = 0b0010'0000 0000'0000 = 0x3000

gaunt lintel
#

prob has been said already but in a nutshell: file io is slow, super super slow. the part that makes it slow is mostly finding the data. once found the actual reading/writing is okay.

bc of that its much much faster to, once located, read a big blob of data - more than possibly needed right now.
than to later figure out "uh shit i need more data" and send another request

#

imagine u go to the grocery store. and while ur there u already purchase some extras that u didnt really need right now, just bc u prob would need them tomorrow anyways

#

so by buying both while ur there already u spare urself going there again the next day

#

practice shows that if someone wants to read some byte, its hiiiighly likely they will very soon also want to read the next bytes. so hence it just reads ahead

#

this idea is also applied elsewhere. for example cpu caching

#

cpu cache is much faster than RAM. loading a byte of data from the RAM will have ur cpu also load it's neighborhood into its cache while it's there already

#

this is the reason why arrays are so incredibly fast, since all their data is right next to each other

#

so doing for example array[4] will not only read that index but internally already load hundreds of neighboring indices of that array into the fast cpu cache

quartz copper
#

Little bit of a drift-off into caches:
And there are multiple types of caches, most commonly you'll see CPUs with 3 cache layers/levels.
The L3 cache or last level cache (LLC) is the biggest and slowest cache (still much faster than memory). This cache is shared amongst all cores.
Then there is the L2 cache, which is a lot faster than the L3 cache again at the cost of being smaller again. Usually these will be individual for each core.
And lastly there is the L1 cache, which is the fastest cache (access times of 1-2 nanoseconds iirc) but again smaller and it is "always" per core.

For example my 4 core CPU (it is rather old but hey), has a shared L3 cache of 8 MB, one 256 kB L2 cache per core and one 64 kB L1 cache per core.

How exactly the CPU decides what data to pre-fetch is incredibly complex and one of the big ways for manufacturers to speed up their chips is by improving these predictions. But yeah, huge, complex field of study, won't get into that too deep, especially since that's also where my knowledge ends.

magic blade
magic blade
quartz copper
gaunt lintel
#

the explanation did sound on point to me